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ABSTRACT 

This is the third in a series of reports on the 
activity carried out under Project INFO auspices at Stanford, and 
covers the period March 1971 - April 1972. During this time, the 
project has Ijeen principally engaged in continued development of the 
OASIS (Online Administrative Information System) data base management 
system and its implementation at Stanford in four major application 
areas; student, Alumni/Gift, Employee, and Budget. The major 
objective of Project INFO is the design and testing of an inteorated 
computer system for university administration. Of major importance 
during the reporting period was the award of a renewal grant by the 
Ford Foundation to continue the work of the project through August 
1973. The work of the OASIS development team in the period since the 
last progress report has focused on completion of a nunber of system 
features not present in the prototype version, on adapting OASIS to 
new application requirements as they have become known, and on 
preparing for and supporting the installation of OASIS at two sites: 
The University of Vermont and Sherbrooke University. Appendixes 
include: Network programing Techniques, Dissemination Activities, and 
OASIS Data Element Dictionaries. (Author/PG) 
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SECTION 1 - INTRODUCTION 

This is the third in a series of reports on the activity carried 
out under Project INFO auspices at Stanford, and covers the period from 
March 1971 through April 1972. During this time, the project has been 
principally engaged in continued development of the OASIS (Online 
Administrative Information System) data base management system and Its 
implementation at Stanford in four major applications areas - Student, 
Alumni/Gift, Employee, and Budget. 

The major objective of Project INFO is the dCoign and testing of an 
Integrated computer system for university administration. Significant 
milestones in the course of the project to date have been the adoption 
of a design for a Stanford developed data base system in early 1969; 
prototype operation of the system, now known as OASIS, in October 1970; 
creation of online files for the first three application systems In 
January 1972; and implementation of the OASIS Student Records and Reg- 
istration system during the Spring Quarter, 1972. 

Of major importance during the reporting period was the award of 
a renewal grant of $190,000 by the Ford Foundation to continue the work 
of the project through August 1973. These funds will contribute to 
application development and provide for an active program of external 
dissemination ov OASIS, applications developed at Stanford, and reports 
on its periarmance and economics. Additional background material on 
Project INFO and the scope of current activity is contained in Appendix V, 

The work of the OASIS development team in the period since the last 
Progress Report has focused on completion of a number of system features 
not present in the prototype version, on adapting OASIS to new applica- 
tion requirements as they have become known, and on preparing for and 
supporting the installation of OASIS at two non-Stanford sites - the 
University of Vermont and Sherbrooke University in the Canadian Province 
of Quebec. Additional detail on OASIS is provided in Section 3. 

In order to provide appropriate manageriel direction for the first 
four systems to be put into operation at Stanford using OASIS, formal 
responsibility for the final design, programming, testing^ and con- 
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vei'sion of each application was assigned to the Systems Development 
Group, another part of the Management Systems Office in which Project 
INFO is located. A detailed presentation of applications work is 
contained in Section 2 and the Appendix. 

An active program of external disseminat-^on has been continued. 
One volume of OASIS system documentation, dealing with Application 
Programming techniques, was published in August of 1971. The OASIS 
Newsletter, an informal means of communication of OASIS developments, 
is now being published each calendar quarter and distributed to a 
mailing list of approximately four hundred. An OASIS Workshop was held 
on the east coast at the Massachusetts Institute of Technology at the 
end of October 1971. A total of seventy-seven individuals from a 
variety of higher education organii^ations attended the two day sessions 
Additional material on dissemination is contained in Appendix II. The 
condensed proceedings of panel on university MIS planning which was 
held at M.I.T. during the October workshop can be found in Appendix III 

As appMcation systems designs have proceeded toward actual imple- 
mentation, there has been a continuing evolution in the file contents 
and layout. Because of the data base aspects of OASIS, in which ref- 
erence to data elements is essentially divorced from their physical 
location and representation, changes to the files have been able to be 
made with minimal impact on the system development and programming 
process. Current data element dictionaries for three OASIS systems-- 
Student, Alumni/Gift, and Employee - are contained in Appendix Vi. 



SECTION 2 - APPLICATION DEVELOPMENTS 

2.1 Background 

In the last several years, application development and maintenance 
responsibilities of the Systems Development Group have increased rapidly 
in scope and level of complexity, mirroring similar developments in the 
University administration generally. At the end of 1971, a staff of, 
25 was occupied with support for more than 40 separate applications of 
varying sizes. The addition of implementation responsibilities for the 
four major INFO application systems in March 1971 added substantially to 
the workload of the group and emphasized a need for a more formalized 
procedure for systems development. After several man-months of effort 
by senior staff members in SDG, a set of procedures was developed which 
are known as DIP (Design and Implementation Plan). The objectives of 
the plan are to: 

- Provide a consistent approach to solving systems problems 

- Detail the organization and content of system documentation 

- Produce documentation as a by-product of development effort 

- Facilitate transfer of maintenance between SDG staff members 

The DIP procedures were adopted for all SDG work in progress in 
late 1971, and will be used for all new v^^rk in the future, including 
OASIS applications. A detailed description of the techniques employed 
is contained in Appendix IV. 

2. 2 OASIS Application Design Considerations 

Experience to date in the development of OASIS based system designs 
has isolated certain areas which are common to all applications. The 
following material is provided for the benefit of others who may be 
working on data base oriented system designs. 

(1) File Conversion 

Files for data base systems are generally created by 
converting and merging information from multiple files that have been 
maintained separately for several years. An example of this is the 
OASIS Alumni /Gift file, which is derived from (1) an Alumni Master 
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(2 reels/tape), (2) Gift Master (2 reels/tape), (3) Special Interest 
Volunteers (1 reel/tape), and (4) Pledges (disc). 

Prior to creation of the OASIS source tape the data must be 
organized into logical segments. Some considerations in the design of 
the file are: 

a) Related data should appear in the same segment 

b) Segments are organized by security 

c) Segments are short enough in length to permit '6ETSE6' file 

services in online programs which do not require an I/O area 
of excessive length. 

The original Alumni/Gift file was created by program using the 
three tape files.. The Pledge file was added Immediately afterward from 
card input. 

The program to create the OASIS Source tape from the three input 
tape files required nearly a man year of programmer effort. New def- 
initions of fields required complex condition checking among and within 
the various input files. 

The Alumni/Gift file is sufficiently large (initially 158,253 
records) that for testing purposes a file of 1% of the records was 
created. Reports from previous systems were created from these 1% files 
and were used for conversion validation and program testing. In the 
case of maintenance programs, the file can be restored without excessive 
cost and in the case of file retrieval. Individual program tests take 
but a few minutes of machine time. No program performing maintenance 
functions is used against the full file until thoroughly tested with 
the 1% file. Statistics on the full file are contained in the Alumni/ 
Gift system description on page 14. 

On the 370/146 the creation of the source input tape for OASIS 
required 16 hours. Processing of the input tape to create disc data 
areas and index tables required an additional five hours. These figures 
represent worst case statistics for Stanford applications, In that the 
Alumni/Gift file Is twice the size of the next largest OASIS file and 
approximately three times the size of the average file expected to be 



used at Stanford. The entire file creation process for the prototype 
Employee Data file currently requires two hours of machine time. 
(2) Methods of Transaction Entry 

Three methods of transaction entry are available vnder 
OASIS • direct update from the terminal , deferred update using the ter- 
minal for data entry, and card input to batch programs. 

a) Direct Update: This method provides for entry of each 
transaction from the terminal and execution of the complete processing 
cycle on the data as it is entered, usually Including the following: 

editing of transaction data for both field errors and 
against the master file for logic errors 

- error signaling to terminal operator and immediate cor- 
rection ^nd resubmission of erroneous data 

- permanent change to file contents 

- logging of transaction data to system logging file for 
backup/restart/audit trail purposes 

b) Deferred Update: Transactions are entered from the 
terminal under the control of an online program which does basic field 
editing and creates a temporary disc or tape file, that subsequently 
becomes input to a batch processing file update program. Under this 
system, input can be accumulated for days, or several weeks, so as to 
make only one pass at the file, but transactions which reject when pro- 
cessed against the master file must be printed out on a list and re- 
submitted later. 

c) Card Input: This is the traditional approach of 
conventional batch systems. Data is normally coded on forms, the forms 
are keypunched, the cards are pas >ed against the master file with either 
the cards rejected themselves in case of error, or a printed list of 
errors created, and the errors rekeypunched and reprocessed. 

In comparing these three methods, the following criteria are 
important: 

a) Reliability: All three methods are reliable, assuming 
that the system is designed to employ adequaio checks and controls on 
the data and to provide adequate recovery procedures if something goes 
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wrong (e.g., hardware, program, or operations error). Recovery tech- 
niques for the direct terminal method might be somewhat more expensive 
than for the other methods, as a file rebuild may be necessary under 
the direct method. 

b) Error Handling: Under the card method, all errors 
must be corrected from a reject list, and data resubmitted to keypunch. 
Because the data is both coded and keypunched, the chance for errors 
existing in the data is greater with card input. Under the deferred 
method, some errors will be noted at entry time and correction allowed, 
but others will appear on a reject list, causing the user to again study 
the transaction and resubmit it. Under the direct method, all errors 
will be corrected through the terminal before the transaction is pro- 
cessed, so there will be no reject list requiring a second look at data 
and resubmission of it. 

c) Timeliness: The direct terminal method provides by 
far the best facility for keeping the file information accurate on a 
day-to-day basis. All information submitted immediately updates the 
file and is therefore immediately available for inquiry, and there Is 
not the sometimes troublesome delay in getting rejected data onto the 
file. However, some of this timeliness is lost if a single day's data 
cannot be entered in a single day through the terminals in the user 
area. The projected transaction volume for example, in the Alumni /Gift 
system is a maximum of 200,000/year or approximately one a minute on 
two terminals, which implies that this will not be a problem, except 
possibly at peak-volume times such as the spring addition of new graduates. 
The card input backup method could be used to take up any overload gener- 
ated at peak-volume times. 

d) Programming Effort: This is the area in which the 
implied preference shown above is reversed. A card input method would 
take the least effort. It is to be provided as backup to either terminal 
method in any case. The queued input method would require less effort 
than the direct, in that data is processed in "batch" mode rather than 

in "online" mode. 



The latter requires the program to be segmented into 2K modules, 
whereas the former allows for a 90K program which is the batch design 
point. It is estimated that the transaction processing program for 
queued mode would take about 25% more effort than the card method, and 
the direct about 50% more effort than the card method. 

Production Cost: The direct method Is the least expensive 
production method for update, because all update is done through the 
terminal and does not generally require coding of input sheets and key- 
punching- In the other methods, however, batch processing at night would 
be an expense that must be considered. 

(3) Modular Programming 

Since the work on application programming for OASIS online 
services was first reported in the February 1971 Progress Report, ad- 
ditional effort has been expended to obtain greater efficiency and bet- 
ter use of memory. An extensive discussion of the techniques now in use 
Is contained In Appendix I. 

(4) Training 

With increasing levels of systems sophistication, train- 
ing becomes an essential ingredient of both specific application develop- 
ments, as well as part of the daily activity of the systems group itself, 

A formal training program* has now been established for all SD6 
personnel, with emphasis in the following areas: 

a) Computer systems fundamentals 

b) ANS COBOL 

c) Systems analysis training 

d) Job Control Language 

e) Testing and debugging 

f) Modularization 

These courses have been conducted Inhouse utilizing video tape medium 
and have been accompanied by expanded standards and guidelines* Ac* 
companying the courses were tutorial sessions In specific OASIS concepts, 
including QUERY,* Report Generator, and Debugging. 

Although user education has been kept on an informal basis, organ- 
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ized class sessions have been conducted for user personnel at all levels. 
The groups are nonnally divided into Management/Supervisory and Clerical/ 
Secretarial, since there would be a slight change in emphasis between 
the two groups. 

Sessions last one to two hours* and the class size is limited to 
5-6 persons. OASIS user training is currently conducted in four phases: 
(1) Orientation; (2) Terminal instruction for Retrieval/Query; (3) 
Terminal instruction for online maintenance; and (4) special fcllowup* 
Individual assistance subsequently is provided as necessary. 

The following outline indicates the general nature of the material 
presented In each training sequence. 

Management Series 

1) Development of formal training plan for 
non-management personnel 

2) Description of elements of final data base 
and expansionary aspects of the data base 

3) Development of alternate reports, discussion 
of Terminal use and how to use the system as 
an effective management tool 

4) Discussion of conversion and implementation 
of system and the impact upon office 
operations 

5) Teach mechanics of Terminal use for simple 
Inquiry 

6) Discuss documentation and procedures manuals 

7) Interview individual managers to help them 
define their reports and show them ways to use 
the system for their specific need. 



Secretarial and Clerical Series 

1) Description of data base and how Information 
is related to their present information 
files 

2) Develop manual drafts and do general 
training into techniques of terminal use 

3) Full discussion of conversion and its 
impact upon their office routine 

4) Full discussion of the impact implementdtion 
of the system will have on present office 
methods and procedures 

5) Demonstration and training in mechanics 
of Terminal use 



6) Discussion of Coding slips and batch 
process routines 

7) Discussion of final drafts of maintenance 
and procedures manuals 

8) Special help to those persons who will be 
responsible for supervisory duties to provide 
the office with full input-output services, 
both online and offline. 

2.3 Summary of Application Progress 

Project INFO application development currently Includes four major 
systems - Student, Alumni/Gift, Employee* and Budget. A brief descrip- 
tion of the scope and status of each is contained in the following pages. 

Although the designs for the four systems may appear to be Indepen- 
dent, there has been extensive consultation and coordination among the 
project teams where functional areas or file contents overlap. Each 
system has an "owner," who Is the ad-nlni strati ve officer with primary 
operating responsibility for the functions which the system is performing. 
In a number of cases, the new OASIS systems are cutting across traditional 
organizational boundaries, e.g., payroll and personnel , and this Is 
requiring certain accommodations from a staffing and job responsibility 
standpoint. Another feature of the new systems Is that there are "users" 
In addition to the staff associated with the "owner." Primarily these 
are planning, analysis, and budget personnel who require access to the 
data base for Information to satisfy study assignments in their own 
groups. Provision is being made In system design and security procedures 
to provide the greatest possible level of immediate access to information 
for planning and analysis witbout compromising the confidentiality of 
data in the files. 

In OASIS systems, the logical file organization is created to meet 
functional objectives of the system, including processing efficiency, 
confidentiality of data, etc. Data capture and validation become and 
remain the primary responsibility of the system owner. This approach 
is taken because in most cases, only the system owner is completely 
knowledgeable about the correctness of file contents. Very seldom do • 
staff analysts or members of the^pomputer group know whether a given 



data element value Is right or not. However, responsfbll Ity for the 
physical Integrity of the data base lies with the Data Base Manager^ 
who is part of the computer facility staff. His duties include building 
files, maintenance of the file dictionary, disc drive assignments for 
the flies, backup/restart procedures, and assignment of passwords. 

The following pages contain Information on the four systems on 
which work Is currently scheduled. The priority for implementation is 
(1) Student, (2) Alumni/Gift, (3) Employee, and (4) Budget. Data 
Element Dictionaries for the first three systems are contained in 
Appendix VI. 



student Record System - Narrative Description 

The system enables the Registrar to maintain records for a Student 
body Of 12,000 so that they are current, accurate and available for 
analysis. The major processes supported are: Registration, Fee 
Assessment, Course Enrollment, Grade Processing, and Compilation of 
Reports, Directories, Roster. 

Inputs (i.e. file changes or additions) originate on preprinted 
forms that are either entered online or keypunched for batch input 
depending on the volume and the time within the quarter. Regular 
weekly runs are normally sufficient to process batch input transactions. 
Additional runs are required during registration and grade processing. 
Also, throughout the quarter, unscheduled changes to the file (about 
100 transactions per day) are introduced through the terminals using 
tailored program networks. Impromptu requests for counts or selected 
lists are handled directly using QUERY. 

Offices contributing data or participating In its use are the 
Registrar's Office, the Admissions Office, the Dean of Students Office, 
the Academic Information Center, the Academic Planning Office, the 
General Secretary's Office (alumni records), and the Accounting Office. 
To continue the usefulness of the Information beyond student days, 
portions of the records of departing students are routinely extracted 
for addition to the alumni file. 

The system is being Implemented during Spring Quarter 1971-72, 
and is expected to be operational by the end of this academic year. 
Additional development to meet specialized reporting and analysis 
requirements will continue in the future. 



STANFORD'S OASIS STUDENT RECORD SYS T E M 



REGISTRAR 

File Maintenance: 
Addrfesses 
Courses 
Grades 

Information Retrieval & Reporting: 
QUERY and TRG 
Tailored Networks 
Batch 

ACCOUNTING : 

File Maintenance: 
Fees 

Informaticn Retrieval & Reporting 
QUERY and TRG 
Tailored Networks 
Batch 

H OUSING & DEAN OF STUDENTS 

File Maintenance: 
Housing Assignments 
Room and Board Table 

Information Retrieval & Reporting; 
Batch 

ACADEMIC INFORMATION CENTER 

File Maintenance: 
High School Activity 
Freshman Housing Assigrments 

Information Retrieval & Reporting: 
QUERY and TRG 



FILE STATISTICS 

No. of Records 20,888* 
No. of Distinct Segment Types 

No. of Elements Defined 185 

No. of Elements Indexed 29 

Average Record Length 588 
Total No. of Characters , 22,000,000 

Est. Annual Input Transactions 151,000 



SCHEMATIC 





STUDFNT 
LOAN 
FILE 



ADDRESS TNFOIWTION 



ADMISSIONS DATA 



ACADEMIC HISTORY 



ACADEMIC COMMITMEMS 



FEE ASSESSMENTS 



HOUSING INFOflMATION 



TABLE OF CODES 



TABLE OF 
COURSE OFFERINGS 
& TIME SCHEDULE 



TABLE OF 
INSTITUTIONAL 
NAMES & ADDRESSES 



EMPLOYEE 
FILE 



OUTPUTS 




ALUMNI /GIFT 
FILE 



♦Includes data on approximately 8000 recently 
but not currently enrolled students 
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ANFORD'S OASIS STUDENT RECORD SYSTEM 
SCHEMATIC 





AODRESS INFORMATION 



ADMISSIONS DATA 



ACADEMIC HISTORY 



ACADEMIC COmiTHENTS 



FEE ASSESSMENTS 



HOUSING INFORMATION 



TABLE OF CODES 



TASIE OF 
COURSE OFFERINGS 
t- TIME SCHEDULE 



TABLE OF 
INSTITUTIONAL 
NAMES 8 ADDRESSES 



OUTPUTS 




STUDENT 
LOAN 
FILE 



EMPLOYEE 
FILE 



ALUMNI /GIFT 
FILE 



REGISTRAR 

Advance Registration List 

Permit-To-Register 

Hold on Registration Lists 

Confirmation of Registration 

Address Data Edit Li jit 

Cour'-.e Data Edit List 

Address Roster 

Student Directory 

Health Service Folder Labels 

Address Labels 

Advisor Code Lists 

Course Offering Lists 

Class List 

Grades 

Electrical Engineering Grade list 
Engineering Grade List 
Freshman Performance 
Transcripts 

Degree Candidate Lists 
Provost's Report 
Utility Lists 



HOUSING/DEAN OF STUDENTS 

Housing Draw - Assignment Cards 

Residence Rosters 

Non-resident Students in Housing 



ACCOUNTING 

Edit Fee Data Lists 
Fee Assessment Batch Proof Lists 
Fee Assessment Statistical Reports 
Edit Housing Fee Data Lists 
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Alumni/Gt ft System •« Narrative Description 



The OASIS Alumn1/61ft system contains a number of specific 
features designed for the fund raising office to assist In conduct of 
g if t procurement programs and campal gn acti yiti es that 1 he lude volunteer 
management and general progress of the several concurrent campaigns 
conducted annually by the University, In addition to general file main- 
tenance support of the alumni area. The newly announced Capital Cam- 
paign at Stanford will be fully supported by the system, 

Maintenance of all non-financial data will be accomplished by 
direct online update with terminal entered batch update used for gift 
processing. Transactions will be entered from terminals installed in 
the Office of Administrative Records. \ 

Information retrieval needs of both records maintenance and fund 
raising personnel will be met by a combination of tailored online net- 
works, specially written OASIS batch programs, and use of the QUERY 
and Terminal Report Generator services. Scope of these requirements is 
indicated on the system schematic (following page) . 

The system is currently in test stage and will begin to support the 
Annual Gift Campaigns in September, 1972. Subsequent system features 
will become operational as they are tested and validated. The system 
is expected to be fi!lly operational by the end of the first quarter 
1973. 
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STANFORD'S OASIS AlUHNI/GIFT SYSTLH 



SCHEMATIC 



ADMINI STRATIVE RECORD S OFFjCE 

(Alumni Information) 

Maintenance : 
Gift Processing 
Pledge Processing 
Campaign Processing 
Basic Personal Processing 
Special Interests Processing 

Retrieval : 



Tailored Inquiry 
TRG 

Batch Report Requests 



GENERAL SECRETARV'S OFFICE 

(Fund Raising) 

Retrieval : 
General ized Query 
TRG 

Tailored Inquiry 



AlUMNI/GlfT 
FILE 



BASIC PERSONAL 
INFO 

SPECIAL INTEREST 
INFO 



GIFTS 



CAMPAIGNS 



PLEDGES 




OUTPUTS 



FILE STATISTICS 

No. of Records 180»000 

No. of Distinct Segment Types 86 

No. of Elements. Defined 310 

No. of Elements Indexed 52 

Average Record Length (bytes) 346 
Total No. of Characters 89,000.000 

Est. Annual Input Transactions 2?0,000 
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STANFORD ' S OAStS ftlUHK I/GIFT SYSTEM 



SCHEMATIC 




BASIC PERSONAL 
INFO 

SPECIAL INTEREST 
INFO 

GIFTS 



CAMPAIGNS 



OUTPUTS 




.000 
86 
310 
52 
346 
,000 
.000 



ACCOUNTING: 

Gift Detail Alpha 

Gift Detail Area 

Gift Detail Donor Yype 

Gift Detail Source 

Gift Detail Tag # 

Gift Detail School and Department 

Gift Summary By Area 

Gift Summary Donor Type 

Gift Summary Source 

Gift Summary School and department 

BIOGRAPHIC: 

Prospect Listings to Module Combinations 
Professional Fund Quarterly Listings 
Basic Information Listing 
Alumni/Friend Information Listing 
Confidential Information Listing 
Gift and/or Pledge Information Listing 
Census Reports 
Deceased Reports 

Name/Address only - Special Listing 
Unknown Address 

PROGRESS REPORTS: 

Campaign National Summary 
Campaign Divisional Summary 
Campaign Team Summary 
Campaign Worker Sunvnary 

Mail Appeal Report to Class Agents/Fund Chairman 
Gifts $1000 and Over - All Campaigns 
Gifts - Plus or Minus from Previous Year - Any Campaign 
Gifts - Plus or Minus from Previous Year - All 

University Specify Gift Amount 
Campaign Volunteer Enlistment Inventories 
CofTKnitment Reports 

STATISTICAL REPORTS : 

CFAE Reports 
ACE Reports 

Gifts to Schools and Departments by Purpose 
Gifts to Area by Oonor Type 
Comparative 1 jmmary - by Campaign 
Comparative Summary - by Program 
Comparative Summary - by Fund 
Summary by Source Number 

Gift Detail - Oor.ors of Specified Gift Amount and Over 

Comparative Sufrvrnaries - Rated Prospects 

Gifts by Range and Source 

Gift Analysis by School 

Five Year School Gift Analysis 

SPECIAL : 

Associates Verification Report Form 
Campaign Assignment Card Report Form 
Biographic, Progress, Statistical, Module 

Bui It as Needed 
Directories 

MAILING LABELS: (6 & 7 Lines} 

ID Lines Options are: 

Stanford § only 
Fund ID Stanford § 
Fund ID Stanford # Fund Year 



ACCOUNTING SYSTEM 
Transactions for fund reporting 



Employee Data System - Narrative Description 



; Th^^ payroll and personnel functions of the 

University. The design takes into account the need for meaningful 
empl oyee i nformation as requ i red by emerg 1 ng empl oyer-en.pl oyee rel ation- 
shlps, increased government compliance reporting and mounting financial 
pressures In" the University. 

Employee information (which is vital to this system) originates in 
academic and administrative departments throughout the University. The 
Personnel & Employee Relations Department and the Payroll Office have 
responsibility for file maintenance of data that Is specific to their 
individual responsi bill ties. Two modes of operation will be available 
for collecting information: online terminal data capture and batch 
file maintenance from keyed Input. It is expected that 60 percent of 
all transaction data will be collected onl ine and that the remainder 
constitutes large volume end-of -pay period input, and overflow during 
peak periods in the fall of each year. There arc many traditional 
reports in Payroll and Personnel that will continue to be produced 
because of legal requirements. In addition, it is estimated that there 
will be in excess of 1,500 annual requests for information. Most of 
these will be routine and scheduled. 

The processing functions to be developed Include: 

. Payroll - Maintenance, Benefits Accounting, Special 
Check Processing, Expenditure Accounting, 
Tax Accounting and Reporting. 

. Personnel - Maintenance, Skills Retrieval , Affirmative 
Actions Programs, Benefits Processing and 
Analysis, Job Classification and Pay, Job 
Applicant Processing and Reporting, Faculty/ 
Staff Directory Processing, Insurance Claims, 
Recording and Analysis and Mailing Services 
Processing. 

I 

The system will be Implemented in stages beginning this fall. 
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STANFORD'S OA SIS EMPLOYEE DATA SYSTEK 
SCHEMATIC 



PEftSONNa 
Maintenance 

Basic Personal Processing 
Applicant Processing 
r^^CuUy/Staff Df rectory Processing 
Education i Work History Processing 
insurance Benefits A Claims Processing 
Retriev al 

Generalized QUERY 
Generalized IRG 
Tailored Inquiry 
Batch Report Requests 

PAYROLL 

Maintenance 

Uage and Salary Processing 
Federal 4 State Withholding Processing 
Payroll Deductions Processing 

Retrieval 

Gtneralfied QUERY 
Generalized TRG 
Tailored Inquiry 
Batch Report Requests 



WSIC PERSONAL 

WGC ind SALARY 
DATA 

DCDUCTtONS I 

BEMEMTS momym 

APPIKANT 

FACULTY/STAFF 
OUECTWY 

EOUano^AL i 
WORK HISrOftf DATA 

(NSUftAMCe CLAIMS 

EMPLOYEE TRAINING 
RECORDS 




OUTPUTS 




FllE STATISTICS 

No. of Records 20,SQ0 

No. of Distinct Segment Types iS 

No. of Elements Defined 280 

No. of Elements Indexed 49 

Average Record Length 1,366 
Total No. of Characters ?a, 000,000 

Est, Annual Input Transactions 200»000 



EHPLOYKENT PROC E$CiNG 

Open Personnel Requisitions 
Applicant Skill Retrieval 
Applicants by Job Class 
Applicant Referrals 
Current Promotable Employees 
Recru I tine nt Source Report 
Applicant Rejection by Reason 
Affirmative Action Conwitment Progreis 
Student Employment Utilization ^ 
Employee Terminations 



Empiovee turnover Summary 
Une*nployiT>ent Insurance Claims by Department 
Career Path Analysis 



Employee leave Usage by Department 
Patent Agreett^ent Status 

PERSONNEL INFOR HA T ION >mGEK^NT : 

Employee Status 
Personnel Actions Control 
.Requisition Hourly Status 
Personnel Actions Summary 
Mfnority employment 
EEO-VReport 
Overtime Report 
Faculty/Staff Leave Status 
Employee Education 
Previous Work History 
Appointment Expirations 
FTE Analysis by Department 
Faculty/Staff Directory 

LABOR RELATIONS 

Bargaining Unit tirployee Characteristics 

Bargaining Unit Wage Analyses 

Bargaining Unit Turnover Statistics 

Bargaining Unit Benefits and Claims 

BENEFITS PROCESSING 

Benefits Eligibility and Enrollment 

Long Term Disability Eligibility 

TIAA/CREF Initial Ellgibnity 

Five Year List of Retirements Pending 

Eligibility Changes 

Annua! Compensation & Benefits Report 

to Employee 
Benefit Plan Enrollment Summary 
Benefit Plan Claims 

TRAINING 

Potential 
Training PrOaram 
Training Analysis Report 
Supervisory Training Report 
Skills Trainee Progression h Retention 
Youth Opportunity Program Employee 
Characteristics 

PAYROLL DATA MAINTENANCE 

File MainteiJance Rejects 
Soc. Sec. No. Cross Reference 
Payroll Information Cards 
Pay/Deduction Terminations 

PAYROLL PROCESSING 

Payroll Register 
Direct Deposits Bank List 
Check Register 
Payroll Checks 

PAYROLL REPCH^TING 

Deductions/Reductions this Payroll 
Payroll Budget Distribution 
Soc, Sec. Number Changes 
Annual W-2 list 

Fiscal Year Student Earnings Sunr>ary 
W-2 Address Verification CaMs 

Statements 
Haster File Purge List 

ACCOU?aiNG SYSTEH 

Transactions for expenditure reporting 



Training Program Enrol lees 
Participation 




Budget S^^stem > Narrative Description 



The objectives of the budget system which Is now In preliminary 
design, are to; 

(1 ) Provide an Immediately accessible data base of budget and 
budget related information for planning and analysis purposes. 

(2) Provide for machine generation of budget working documents 
duri ng the annual processi ng cycl e . 

(3) Produce the University budget document by machine. 

(4) Automate the present manual interface between the budget 
system and the University accounting and financial reporting system. 

(5) Make provision for manpower control for personnel management 
and budgeting control. 

In order to meet these design objectives, a number of complex 
interfaces to the contents of other OASIS files, chiefly the Employee 
file, must be worked out. In particular, common agreement among the 
Budget, Personnel , Provost » Accounting, and Analytical Studies Offices 
must be reached on procedures for identifying the number of authorized 
positions of various job types in the University. Discussions on this 
matter have been further complicated by recent new requirements of the 
federal government relating to information on employee minority status, 
job history, compensation history, etc. , 

The contents of the budget file will Include data on three budget 
yejirs - past, current, and projected - and actual expenditure data for 
the last year and current year-to-date. Additionally, a number of OASIS 
indirect file references will be df^fined to data contained In other files, 
which will assist in studying the complex cost relationships which exist 
within the operating budget with the purpose of improved resource al- 
location and control. v 

It is planned to put a prototype budget file into operation in the 
fall of 1972 for terminal inquiry and report generation during the 
1973-74 budget cycle. Based on lessons learned during this period, 
operational support will be provided during the 1974-75 cycle commenc- 
ing in the fall of 1973. 
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2.4 Selected CRT Displays from Student S.ystem 

The pictorial essay beginning on this page contains photographs of 
CRT terminal displays used in the new Student Records system. They are 
part of online networks designed to facilitate the retrieval and mainte- 
nance of student information. A separate network handles each class of 
data serviced by various sections in the Registrar's Office. Three net- 
works are represented in this pictorial: 

(1) Student Address Retrieval and Maintenance 

(2) Student Course List Retrieval and Maintenance 

(3) Student Grade Processing and Class List Retrieval 
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The address information on the student is displayed. The codes 
in the lower right corner indicate that her home and local addresses 
are one and the same, and that her parents are to be contacted in 
case of an emergency. (Note the 'P' beneath EMERGENCY in the SAME AS 
line.) In the example, the user has requested a change in the emergency 
address. (Note the 'C beneath EMERGENCY in the Update Option area. ) 

After the user has entered a specification for a separate emergency 
address, the system processes the request, updates the data record, and 
deletes the SAME AS flag. To assure the user that the change has been 
made, a message indicates that the update is complete. 
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Current student course enrollment Information may be displayed and/or 
modified by means of another of the Student Records system networks. The 
user specifies by quarter any of the course lists, past or present, for a 
given student. He may then modify by line number a course ID or credit 
units. If he alters a course ID, the system automatically returns the 
new department code and course title. 
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In this example, the courses for fall quarter of 1961 (161) were 
requested for student 164 01430. The user signals a change to the fifth 
course by the response CHNG 05. The system positions him at the appropri- 
ate line and automatically tabs between the course ID field and the units 
area. When the change is entered, the system modifies the data record 
and again indicates that the change has been made. (In the example, the 
credit units for PERMAFROST were increased from 2 to 4.) 
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The third network handles two ilia jor functions: 

(1) Class Enrollment Queries 

(2) Grade Posting and Correction 

By specifying a course 10 and quarter designation, the user may review 
the enrollment of any class held in the prior year. Grades can be posted 
or corrected via the same network. The system automatically determines 
which grades have bec-n modified. Those grades are changed in the appro- 
priate data records and a report is returned of how many updates were 
performed. 

In this example, the class list is requested for course 170 700 
201 A 01 of autumn quarter In the prior year. 
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The class list is displayed in student number order. Since this 
class met in a prior quarter, the grades also appear. The user may 
now request more of the same class or the list for another class; or 
he has the option of modifying one or more grades in the displayed 
list. 
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' Grade posting and alteratigns are made directly onto the display 
of the class list. The cursor automatically tabs from one grade field 
to the next/prior one, In the example, the incomplete courses (code IN 
in the previous photograph) are to receive grade postings. The user 
tabs to grade field 4 and changes the IN to the completed grade of 
then tabs to the tenth field and types in a B+. Since these are the 
only changes to this page of StudentSi he send<> the data into the system* 



ERIC 



31 




The system compares the incoming grades with the ones that were 
originally displayed. If there are alterations and the new grades are 
validly coded, the appropriate student records are modified. Finally, 
a count of the grade modifications performed is reported back to the 
user as a control check mechanism. 
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SECTION 3 -OASIS DEVELOPMENTS 

OASIS Is now running 1n production mode at Stanford 1n a machine 
environment very similar to that for which it was originally designed, 
although the 360/40 processor used by the Administrative Computing 
Facility has now been replaced by a 370/145 processor of the same 256K 
byte main memory capacity. Currently a dozen online terminals are sup- 
ported in a 128K partition of the processor, with system activity being 
primarily oriented to application development, as described in Section 
2 of this report. A machine configuration diagram is presented in 
Figure 3-1 . 

3.1 OASIS Modifications and Extensions 

Since the initiation of Project INFO, there has been a close 
working relationship between those responsible for development of the 
data base software, i.e., OASIS, and those responsible for using OASIS 
to solve user data processing and analysis problems. Although there 
have been a number of Instances in which one group was waiting for the 
other to solve a design or performance problem, on the whole the inter- 
action between the two groups has been invaluable, with each benefiting 
from the opportunity to influence the design approach of the other. 
This process is by no means complete, and will continue as more ap- 
plications are developed and put into operation, and as operating 
statistics on OASIS internal performance become available. 

As a result of a year's operating experience with the prototype 
version of OASIS, numerous system modifications and extensions have been 
made. Among the more noteworthy are: 

a) The original relocating loader for online modules was inter- 
faced to the DOS Relocatable Library. In practice, with application 
networks having large numbers of separate modules, the load time of 
about 1.5 seconds was impacting online performance. A new high per- 
formance loader, running against a specialized program library, is 
expected to reduce load time to one hundred milliseconds or less. 

b) Deeper analysis of the problems associated with system re- 
covery and backup support has resulted in an extended design which deals 
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3420-3 
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Figure 3-1 Administrative Computer Facility Machine Configuration 



with both the physcial integrity of the data base, as well as with the 
logical integrity of processing. The difference between the two is 
illustrated by the situation where one logical update might require 
physical updates to more than one record, such as the case in which 
the marriage or two alumni requires changes to both of their personal 
records and to their giving records. Application programs which 
require protection for the chain of physical updates which collectively 
represent a single logical change to a file have been given facilities 
to signal OASIS to that effect and receive recover support in the event 
of a system failure. 

c) A new QUERY feature, named RECORDS, was added in response to 
user developed needs to retrieve the number of records in a given file 
population, as opposed to the COUNT feature, which provides the number 
of occurrences of a named data element, and which may vary from the 
record count in those instances where an element is defined to have a 
variable number of occurrences within a given segment or record. An 
example is the number of gifts which a specific alumnus has given. 

d) Initial use of the extensive software file security features 
of OASIS has been satisfactory, although it is apparent that this 1s an 
area where only extended use will provide a complete understanding of 
the problems. It has been found feasible to provide limited terminal 
security within the OASIS password structure, and this will be used to 
protect certain sensitive Information. A new feature essentially pro- 
vides that certain passwords may be used only from specified terminals. 
If these are the only passwords associated with the sensitive portions 
of a given file, then that portion of the file is effectively accessible 
only from the limited number of terminals which will accept the pass- 
words. The selectivity of this feature allows system wide access to 
nonconfidential portions of all OASIS files, while preserving lockout 
capability on the sensitive file contents. Terminal logon procedures 
have also been revised to provide a password entry area which is dis- 
played in a manner that the password cannot be read on the screen as it 
is being entered. 

e) The support for remote hard copy printers provided by the 
Sanders' standard hardware involves the unloading of the terminal 
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memory buffer to an attached Teletype or Teletype compatible printer. 
For a number of reasons, including locking of the CRT display during 
printing, this support has been found unsatisfactory. A new approach, 
utilizing the UNI VAC DCT-100 30cps printer, driven from terminal 
services code resident in the processor memory, has been provided to 
OASIS users. Although overcoming many of the previous deficiencies, 
this solution requires relatively expensive hardware which results in 
a monthly hardcopy printer cost of $275. Less expensive alternatives 
are under study as part of the review of the next generation CRT 
terminals to be used in OASIS, which is described later in this section. 

f) The task scheduler code contained in the first version of 
OASIS executive control treated each active task as having essentially 
equal priority. As more knowledge has been accumulated about system 
performance, it has become apparent that some discrimination will be 
necessary to avoid tasks With extended I/O requirements, such as large 
Queries, from degrading system response time for other users. Modi- 
fications to the task scheduler have been made to provide the ability 
to discriminate among various types of tenriinal activity. 

g) Management of the temporary disc space required for the 
Generalized Services and for the Select service has been revised, which 
has improved the performance of all of these services and the applica- 
tion programs dependent upon them. 

3.2 System Measurement 

As OASIS enters a live production environment at Stanford, pre- 
vious plans for extensive system measurement are being implemented. 
The measurement project is being aided by the efforts of a graduate 
student from the Electrical Engineering Department with prior systems 
measurement experience. The work has been divided into two parts: 
task measurements and system measurements. Included in task measure- 
ments are all activities which pertain to each online terminal , its 
users, networks, and files used. Time profiles of system use, response 
time, I/O counts, etc., will be generated from the data which is col- 
lected. System measurements will collect information about the oper- 
ation of OASIS Internal programs. Included will be data about resource 



allocation, queue lengths, request conflicts, task scheduling, etc. 

Results of system measurements will be used for many purposes, both 
short and long range, including optimization of OASIS code, balancing 
of the computer hardware configuration, study of the behavior of system 
users as they adapt to a new information processing environment,- and 
projection of the long term unit costs of computing support for Stanford 
administration. 

3.3 Future Developments 

At the initiation of software development work in 1969, a survey 
of administrative computers at other Institutions Indicated that a 
large number were running under IBM's Disc Operating System (DOS) and 
because of this and other factors, a decision was made to interface 
OASIS to DOS as the host operating system. Since that time there has 
been rapid change in the computing environments at many institutions 
and the primary interest of potential external users of OASIS currently 
lies in a version which is compatible with IBM's full Operating System 
(OS). In view of this interest and because of the desire to make OASIS 
and its applications as broadly available as possible, an agreement was 
reached jith IBM early in 1972 for the production of a detailed design 
specification for an OS version of OASI?. This work is now nearly 
complete, and the volume will be published by late spring of 1972. 
The text is addressed to a knowledgeable systems programmer working in 
an OS machine environment, and it is anticipated that the necessary 
changes to the DOS version of OASIS could be accomplished with three 
or four man-months of effort. 

The computer terminal market has been especially active in the 
past year, with many new models being introduced. In addition to 
mechanical and electrical improvements, expanded functional capability, 
and better price performance, the advent of LSI semiconductor memory 
has produced considerable discussion of terminal "intelligence." (See 
Dick Canning's April 1972 EDP Analyzer for a more comprehensive review 
of the issues.) Inexpensive and microminiaturized manory and logic 
have allowed the terminal manufacturers to place many functions which 
formerly required mainframe processor power in the terminal package 



Itself, Including editing and temporary storage of data. 

At the present time, OASIS supports only the Sanders 720 CRT 
terminals* A number of system functions ♦Including line control, 
polling, the Generalized Services, and terminal services provided to 
application programs have been tailored to the features of this terminal. 
In reviewing the possibil ity of adapting OASIS to the new generation 
terminals, it has become apparent that the largest part of the task 
involves the necessary changes to OASIS software. Any proposaV to 
replace the Sanders terminals must include better price performance, 
extended capability, and future adaptability to changing system require- 
ments. Very little of the detailed study necessary before a new terminal 
can be selected has been completed at this time; however, it is likely 
that a new terminal interface will be developed and made available 
during the summer of 1973. Possible replacements for the Sanders 720 
include the IBM 3270, Sanders 804, and Four Foase System IV. 

3.4 Support for External Users of OASIS 

In the summer of 1971, OASIS was made available on a limited 
pilot test basis to institutions desiring to Include the system in their 
computer development plans. It subsequently was put into operation at 
the University of Vermont on a 370/145, and in the Canadian province of 
Quebec at the University of Sherbrooke on a 360/40. 

It has been found essential that at least one person from the 
receiving institution spend a three day orientation period at Stanford. 
This has been particularly necessary in the last year because full 
documented ti on was not available and the system was not yet in a stable 
production version. Following the orientation period at Stanford, 
assistance has been provided by means of mail and telephone consultation, 
site visits, and periodic distribution of system changes. 

Continuing support for external users of OASIS was requested and 
received from the Ford Foundation as part of the renewal grant. Until 
the expiration of current funding in August 1973, a senior member of 
the staff will be available on a full-time basis to assist other 
institutions who wish to use OASIS as part of their administrative 
computer system. 



Appendix I- Network Progranmtng Techniques 

This appendix is intended to give a brief discussion of the ad- 
vancements that have been made in network programming since the first 
prototype online network was developed under OASIS. 

Unlike programming in a batch environment, online programming 
under OASIS has a limit of 2048 (2K) bytes per module. This concept 
necessitates a network system design which can perform all the functions 
of a batch program while maintaining a rigorous modularity. GS0502 
is an online retrieval and update network which is used in this ap- 
pendix to illustrate how these conditions can most effectively be 
satisfied. This network will soon be used in production at Stanford. 
Throughout the execution of this network, no more than two levels of 
2K modules occupy memory at any given time. In all, there are over 
112 modules involved in its processing Including the root module 
which is always resident during execution. In OASIS networks, the 
first module to be linked to an active terminal is known as the root 
module. It normally contains the data areas used by other modules, 
processes messages and data from the terminal, and handles routing to 
other modules. It Is sometimes difficult to find sufficient space for 
the data areas (i.e. COBOL - working storage) in the root module. 
This can be remedied to a major extent by making sure that working 
storage Is redefined as much as possible with common information con- 
tained in the first portion of working storage. The portion of work- 
ing storage that is not needed for common usage in the network can be 
defined as one large area (i.e. 05WS - AREA PIC X (700) VALUE SPACES) 
and used as the last item. Subsequent modules can use this area by 
redefining it for specific needs of that module. Care must be taken 
however, not to lose information through intervening calls of other 
modules. 

In most terminal networks two types of routines can be identified, 
those which emphasize common functions needed by all phases of the 
network and those which are unique to a given series of modules. Net- 
works should be written in such a way that these two kinds of routines 
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are Independent of one another. The comnion routines are those which In- 
volve any kind of I/O activities such as a 'GETSE6' (retrieve data from 
file) or 'TGET' (accept response from terminal). Specialized routines, 
on the other hand, involve processing that is peculiar to a given module 
or modules such as editing a user response during an update. 

An important concept to keep in mind when designing a teleprocess- 
ing network is to be aware of what the terminal user is seeing and re- 
sponding to. Uncertainty by the user as to what is happening should be 
minimized through frequent display of information and error messages. 
Through both retrieval and updating cycles of a network, it is beneficial 
to inform the user as to the result of information he has requested or 
entered; i.e. if information requested cannot be found or if invalid 
input data is rejected, an appropriate message should be displayed to 
the user. Also, it is helpful during network development to display 
the result of any error conditions which result from the file service 
or terminal service calls. The same area that is to be used by the 
terminal operator when the network becomes operational can be used 
by programmers during the development phase. OASIS provides a return 
code area that carries the result of all file service requests. If the 
request is in error it is not necessary to terminate the session at the 
terminal, simply display the return codes and continue with the next 
response. This technique will assist the programmer during the de- 
bugging phase of a network. 

The following material illustrates application of the network 
concept to two typical functions required by the terminal user: the 
retrieval of a specified segment, and the updating of information con- 
tained in the segment. Each procedure is called a cycle, and requires 
loading and execution of a number of modules, which have been assigned 
two letter identifiers. A cycle is initiated by a "Send Block" request 
from the terminal for service, and concludes with the display of new 
information on the terminal screen. The example is from the portion of 
the Alumni/Gift network dealing with special program information. After 
each module completes execution, it branches back to the root module 
and releases its memory space for the next module required. 
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Begin Cycle 1 - Retrieval 

(1) HODULE^AA i This modul e performs various initialization and term- 
ination routines such as attaching and detaching the user files, and 
display of the signoff message whenever the end of a terminal session 
occurs. It begins the retrieval process by displaying the options 
available to the user. In this case, the user wishes to look at special 
program Information and specifies "PR06" plus the identification number 
of the person sought, Mr. Sam Smith. 
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(2) HODULE-AB ; Thi s modul e analyzes the user response and sets up 
file service parameters for member ID, which Is in segment 1. If an 
invalid response optlor is detected, the parameters are set up to dis- 
play this error condition to the user. 



(3) MODULE-AC : This module retrieves segments from the file via the 
6ETSE6 (retrieve data from file) call. The parameters for the GETSE6 
service are already set up when this module is called* When the last 
occurrence of a given segment Is reached, an indicator is set. Sub- 
sequent modules test this indicator and follow the appropriate paths, 

(4) MODULE-AD : This module checks the return code area from the pre- 
vious 6ETSEG call. If the requested ID was found In the file/ the ID, 
name, and title from segment 1 are formatted In the terminal display 
area. Once this is done, the correct module is selected to retrieve 
the segment containing the Information requested by the user via his 
response option; I.e., one of ten module names will be set at this 
time. If ID is not found, an error message is issued. 

(6) MODULE-BA : Since PROG was the option chosen by the user, MODULE- 
BA Is entered. Since special programs (segment 102) can occur only 
once for a given member, the GETSEG parameters for segment 102 occur- 
rence 1 are set up here. The module-name-save area is set to 'BA', 
since we want to reenter this module to check the results of the 
GETSEG call for segment 102. Module name is set to "AC (commpn 
GETSEG). If segment 102 was found for this member, the codes in that 
segment are placed In the display area with their appropriate expansions. 
If segment 102 was not found, the message 'SPECIAL PROGRAMS NO! PRESENT 
FOR MEMBER' Is displayed. In this example, segment 102 Is not present 
for the member. 

(6) MODULE-BI : Since this pa^^ticular network has ten different dis- 
play formats, MODULE-BI analyzes the response the user has requested 
and Preformats the terminal screen. The completed display is shown in 
step (7), MODULE-AH. 



(7) MODUU^AH : This module perforrrts all terminal display functions 
for the retrieval phase of the 6S0502 network. The screen format con- 
sists of from 1 to 10 blocks of information. Upon exit from this module, 
the TGET- indicator is turned on, because a response from the user will 
be expected, thus ending cycle 1. 




End CYCLE 1 



Begin CYCLE 2 - Update 

(1) MODULE-AB ; Because the TGET-indlcator was turned on In MODULE-AH, 
the T6ET function was called In the root module to accept a new user 
response; cycle 2 begins with this new response. 

MODULE-AB again analyzes the respoJise option that was entered and 
the appropriate module-name is set. In this example, the user entered 
ADD as his response. Since the previous response was ^ROG and the 
member ID has not been changed, the system determines that segment 102 
(special programs) is to be added to the current member's record - 
MODULE-AB sets up the call for MODULE-AI, the update response routing 
module. 

(2) MODULE-AI ; This module determines which of the three update re- 
sponses (ADD, CHNG, DLTE) has been entered. Once this is determined, 
the module that will analyze whether or not the update request is valid 
is set. Since there are 10 retrieval options and three update options 
available to the user, one of 30 updating module routines is set up at 
this time. In this example, the user desires to add a special programs 
segment 102 to the current member's record: MODULE-AP is moved to 
module-name, 

(3) MODULE-AP : This module is entered to validate the user's request 
for adding an occurrence of segment 102 to the current memher^s record* 
At retrieval time, it was determined if the segment existed for this 
member. If it did not exist, the user's request for an addition is 
valid and the appropriate validation module is set. If it did exist, 
the risponse ADD would be considered invalid and the appropriate error 
message module would be set. If the request had been CHNG or DLTE, 
the appropriate validation or error message module-name would have been 
set up according to whether or not the segment existed. In this example 
the request for addition is valid and the validation message MODULE-AN 
is specified. 



(4) HODULE^AN ; This module issues validation messages to user 
prompts of ADDi CHNG, or DLTE for various segments being updated In 
this network. For multiple occurring segments^ a line number of 1 
through 5 is part of the display. The user need only Indicate which 
line he desires to update. In the case of additions, the next avail- 
able line number is calculated for the user. In the case of segments 
which occur only once, such as segment 102, the message 'PROCEED WITH 
ADDITION' is Issued, depending upon the user's update response. In 
this example, ^PROCEED WITH ADDITION* appears: 
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(5) MODULE-AR ; The major portion of any maintenance program Involves 
the editing of data, MODULE-AR Is one of numerous editing modules in 
the GS0502 network. This particular module edits the special programs 
codes entered by the user» If any invalid code is encountered in a 
response area* the error message subscript is set, and the appropriate 
error message module 1s called, Upon exit from the error message 
module, module-name is again set to the edit module needed for the up- 
date currently in progress. It Is only when all valid codes have been 
entered that the system will proceed to update the file. If at any 
point in the editing cycle the user decides he does not want to continue 
the updating process, the user can respond with an *; this response will 
result in the options page appearing on the screen, at which point the 
user may enter a new response. 

(6) MODULE- AO ; The GS0502 network has the capability of updating 14 
different segments; the segment-IO area is redefined as many times as 
there are different segment types, thereby making it impossible to carry 
the segment type and occurrence in the segment header area. MODULE-AO 
is entered in order to determine which segment type is currently being 
updated so that the proper segment header can be moved to the header-IO 
area before the updating file services are called, 

(7) MODULE-AJ ; The actual updating of the file occurs in this module. 
This particular module performs additions to the file via the ADDSEG 
service. Other modules handle changes and deletions via calls to the 
appropriate File Service. All the parameters required for the update 
services are complete by the time this module is called. In the event 
the file update is invalid, an error message will be issued specifying 
the type of error, and the module that accepts a new user response is 
called. At the same time the file is updated, a transaction tape is 
written reflecting the old and new information, depending on the update 
function currently in progress. In this example, the same addition that 
is used to update the user disc file is reflected on the user logging 
tape. This tape can be used at a later time to report the user^s 
terminal activities. 



(8) MODULE-AG : With each update of the file, It Is necessary to in- 
dicate the most recent date on which a segment was altered. Segment 1 
in this file carries a last transaction date. This module Is entered 
only when a valid update has occurred in order to replace the existing 
transaction date with the current date as reflected in the communication 
region. 

(9) MODULE-AF : Once all updating routines have been completed, the 
procedure for redisplay of the updated segment is initiated. MODULE-AF 
determines which of the 10 options is currently 1n progress and sets up 
the proper redisplay series of modules. In essence, MODULE-AF functions 
as a redisplay routing analyzer. 

(10) MODULE-DO : At this point, the segment chosen by the user via his 
response options has been updated. MODULE-DO sets up the parameters to 
retrieve the updated segment. In this example, segment 102 occurrence 

1 Is retrieved. Upon the original retrieval of this segment in cycle 1, 
the File Services return code area indicated that the segment was not 
found. This in turn initiated the user's update routine. The request 
for segment 102 will now be met with success, and the codes will be 
formatted with appropriate expansions. 

(11) HODULE-AS : Once the codes have been positioned in the display 
area with their proper expansions, the TPUT routine is called in order 
to display the Information on the terminal screen. In that the basic 
page format for special programs is already present on the screen, it is 
not necessary to reissue a TPA6E. Instead, only the blocks of infor- 
mation that reflect the update are displayed; thus, an unnecessary 
terminal I/O is avoided. 
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(12) MODULE-ZC : This module is the last module called in the updating 
sequence. It issues file update verification messages. Upon exit from 
this module, the TGET-indicator is turned on, since a new response from 
the user will be requested. The user may request further retrievals 
or continue updating this segment. The resultant screen appears as 
follows and completes cycle 2, 



ffiis Hf MBf p is rmssirni rs f liii iiws 

RSSIL^JEJI 

PffDSPfTF f[)P gfSUfSf GIF! 



End CYCLE 2 
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Appendix II - Dissemination Activities ! 

A second general introductory workshop on OASIS design principles 
and operating featur-^s was held at M.I.T. at the end of October, 1971. 
The format was generally the same as that presented in the first work- 
shop at Stanford in January of that year but without the benefit of 
live terminal demonstrations. The workshop program will be continued 
during 1972. and 1973, but the emphasis will shift to presentation and 
discussion of the application systems which are being developed for 
Stanford use of OASIS. A participant list for the M.I.T. Workshop is at 
the end of this appendix. 

The first volume of OASIS documentation, an Application Programmer's 
Guide, was Issued in August of 1971. This is the second in a sequence 
of three volumes of planned documentation. The third volume, a System 
Maintenance Guide , will be published in the summer of 1972, and the 
final volume, which will contain general design and performance guide- 
lines, wit] appear during 1973. The addition of a technical writer to 
the staff In the fall of 1971 has given added impetus to the document- 
ation effort. 

A companion to the Application Programmer's Guide is the OASIS 
Programmer's Reference Booklet . This compact document contains formats 
and calling sequences frequently referenced by application analysts and 
programmers. . The 16-mm color/sound film "This is OASIS" continues to 
be in demand for showing In both the United States and Canada. 

Three issues of the OASIS Newsletter have been published and dis- 
tributed to a mailing list of approximately four hundred. The Newsletter 
is designed as an informal medium of cormiuni cation concerning OASIS devel- 
opments at Stanford and elsewhere. 

As described in Section 3, considerable effort has gone into training 
of personnel from a number of other institutions. This program will con- 
tinue in the future within the limits of project staff availability. 

Presentations on OASIS were made to the SIGBDP meeting at the Fall 
Joint Computer Conference in Las Vegas, the ECS Forum in Denver, the 
California Educational Computing Consortium in Long Beach and Palo Alto, 
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and the Electronics Application Research Forum in San Francisco. The 
S16B0P meeting presentation is to be published in a forthcoming issue 
of "Data Base" and has led to OASIS being featured in a forthcoming 
issue of EDP Analyzer, a leading industry newsletter. 
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Appendix III 



College and University MIS Planning 



Introduction. The following material is a partial transcription of the 
proceedings of a panel discussion on MIS planning conducted during the 
Project INFO Workshop at the Massachusetts Institute of Technology during 
October 1971. We are indebted to Landra Miles of M.I.T. for her services 
in recording the discussion and preparing the transcript. 

Participants . 



Charles R. Thomas, Executive Director, College and University 
Systems Exchange (Panel Chaimian) 

Michael M. Roberts, Director, Management Systems Office 
Stanford University 

Robert H. Scott, Director, Information Processing Services. 
M.I.T. 

Paul W. Sire, Director, Office of Management Information Systems 
and Computing, University of Vermont 

Henry G. Vaughan, Director, Division of Management Systems and 
Analysis, Cornell University 



Presentations . 
Mr. Saott: 

We have recently fonmed an Office of Administrative Information Services 
(OAIS) to bring together the financial data processing of the Institute and 
other data processing in administrative areas, e.g., personnel, space, etc. 
The reasons for bringing these different areas together are threefold: 

• It enables the Institute to use data describing its status and 
operations as flexibly and economically as possible. 

• It brings about a greater coordination and planning in our systems 
development activities. 

• It enables the Institute to find better ways of analyzing and 
Improving its operations. 

In considering the management of administrative data processing and the 
development of administrative systems, there are several modes of action that 
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should be avoided: 

• Avoid the major upheaval approach. There needs to be a great 
deal of preliminary groundwork, 

• Avoid making changes by dictum from above. 

• Do not conduct a great deal of planning at the senior level 
without also beginning planning activities at the middle level. 

• Changes rarely can be contained within a single administrative 
department; effects on others must be planned for early. 

Some approaches that do work include the following: 

• Evolution rather than revolution; no organization can handle 
constant reorganization. 

• Any feasible approach must demonstrate both functional and 
economic gains in the short term; plans with only long term 
savings get swallowed up in the changing institutional environ- 
ment. 

• A systems development and planning methodology which is based 
on a coordinated, team effort by both the computer staff and 
the system users. 

• Recognition on the part of presidents and vice-presidents that 
good management costs something, and that good day to day per- 
formance follows only from previous, carefully planned. Invest- 
ment decisions. 

Mr. Sire: 

At the University of Vermont we have recently completed a comprehensive 
systems study effort at the departmental level. 

Until August of this year, both administrative and academic computing 
was serviced by an IBM 360/44. In August, an IBM 370/145 with 248K memory 
was acquired for administrative processing and an XDS Sigma 6 Time-sharing 
System was installed in support of instruction and research. 

Before acquisition of the 145, i.e.. In the spring of the year, it was 
proposed that inter- and intra-departmental information flow within the uni- 
versity be thoroughly analyzed. This was done in the period July-October 
using IBM's Study Organization Plan (SOP) as the analysis and documentation 
technique. Odr overall goal: new systems and data base design recommendations 
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in the Student (Admissions, Financial Aid, Counseling and Testing, Student 
Records, Registration and Reporting), Staff (Personnel, Payroll and Payroll 
Distribution), and Facilities (Inventory and utilization) areas. 

The next phase will be design per se within a data management framework. 
In this regard we have evaluated both IBM's IMS II and OASIS, out of Stanford's 
Project INFO. IMS was found to be too sophisticated and demanding for our 
hardware conftguration. Thus, we have decided to go with OASIS which is now 
operational in pilot-test using a subset of our personnel file. 

As we move on into new systems design, our initial proposals will include: 
data base elements and files (e.g. , in the student area, the establisfxnent of 
a cumulative record) , macro-flow diagrams, economies, input documents, reporting: 
scheduled, exception, controV and demand (re: demand reporting: the ability 
for an academic or administrative user to directly inquire into, or format 
simple reports for quick response from, the student and staff data bases), 
target dates for operational status, systems staff assignments, and definitional 
requirements. 

I might mention in conclusion that of 29 people, U will be assigned to 
our systems development and implementation effort. 

Mv, Roberta: 

I am very much In agreement with Bob Scott's comments on good and bad 
ways to pursue planning, and because you are already hearing so much about 
OASIS during these two days, I will not elaborate further. However, one 
point that I believe needs to be made is that it takes time to do good planning, 
and in the crisis mode in which most universities and all data processing shops 
operate, time for non-emergency items is a very precious cormodity. The com- 
puting manager has to make sure his subordinates make time for planning, and 
he has to make sure he gets support for planning from his superiors. 

Aft». Vaughan: 

Cornell is in the same hard pressed financial situation as most other 
universities, with the additional complication of being both publicly supported 
by the State of New York in some fields of study, and privately supported in 
the endowed colleges. We are both data poor and system poor, and currently 
running all types of computing together on a 360/65. We have a requirement 
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for Iwnedi ate answers to a number of Informatton problems* as well as the 
longer run system planning and Implementation. 

In reviewing various ways of moving ahead from our present situation, 
we found the following advantages In a data management system approach: 

Integrated file structures 

Modular system building 

Simpler application programs 

Standardized and efficient file manipulations 

Simpler file reorganizations and redesigns 

Evolution to teleprocessing 
But such systems also have the following disadvantages: 

Thorough planning required to be efficient 

Interdependency of users causes more definitive management 

Limited system backup- 
University data files are typically divided Into four divisions: 

Personnel Information 

Financial Information 

Student Information 

Alumni information 

In planning the reorganization of these data files one must ask what Is your 
data base and decide who Is responsible for the data. Usually, the payroll 
and personnel data files can combine. This leaves student information In a 
separate data file which provides for students to be transferred Into an alumni 
file when no longer active students. 

Mr. Vaughan then went on to explain how he would use these MIS tools to 
solve problems: 

Design separated from development 

Formal documentation 

Formal buy-offs 

Periodic project reviews 

Formal reports 

Mr. Vaughan gave as a case study the reorganization of the student regis- 
tration system, the last of the 1401 software that remained at Cornell . Although 
they looked at OASIS, they decided to go with IMS. They started with batch pro- 
cessing with the hope of following this with teleprocessing as soon as possible. 



In reorganizing the student registration system, CorneH proceeded In steps: 

1. Define the customer. 

2. Define the problem as precisely as possible. For this a formal 
document (User Requirement Specs) was used. 

3. Define a feasible overall schedule and get approvals. 

4. Define policy questions and get answers. 

5. Develop alternative design analysis and decisions. 

6. Determine Individual software design specifications. 

7. Organize development group. 

8. Monitor progress and assist customer In preparation. 

9. Provide for acceptance testing and "production" status. 
10. Perform follow-up analysis (and assistance). 

Today the main question is now much teleprocessing, how fast, limited by how 
much. 



Question and Answer Period . 

Q. - (for Vaughan): What are your feelings about research. Instruction, and 

administration on one system? 
A. - It does not work particularly well. Cornell Is actively considering- 

separation. 

Q. - (from Roberts to audience): How much time and energy should you expend 
to keep users with you? Do you feel that: (a) It's about time that users 
find out about computers--- the systems group has to assume a training 
responsibility In this area; or (b) you are so far ahead of them already 
that It is a losing proposition— -don't bother them with understanding? 

A. - (Vaughan): At Cornell the Registrar, Director of Personnel, etc., 
were formed into a planning board. This has now been replaced by a 
technical board and a broad policy board. You must talk to the user in 
the particular area. 

(Scott): You must follow the former road. You need middle level under- 
standing. Try bringing together a group to give technical advice but not 
necessarily representing all the offices, just the people who are really 
interested. 
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(sire): It depends on the people In the university coimiunlty. Some 
administrators are keenly Interested, but when directly asked what they 
want in the system, they don't give an answer. You must Implement your 
Ideas as director If you are not getting much feedback. 
(Audience); You should be able to say to the user, "You tell us your 
problem as we will analyze It In computer terms." Too often the user 
attempts to do design himself, with unfortunate results. 

- (Thomas to panel): What about advance documentation of costs and benefits 
of a new system as compared with the old? 

/I. - (Scott): The greatest problem Is that you can make estimates but you tend 
not to make the savings because of failure In personnel dealings. For 
example^ a secretary who has been there a long time may not be dismissed 
as Intended, which is not a failure in the system, 
(Roberts): On any major system^ the total cost benefit picture cannot 
be shown in^the beginning. Management has to insist on periodic reporting 
with validation of savings as the system goes into full operation. 
(Sire and Scott): New systems will almost always have a large quality 
Improvement in timeliness, scope of reports, ease of access to data, etc., 
that is hard to put a price tag on. 

(Roberts): As a practical matter, most users will want you to deliver 
all the improvement you can without significantly raising costs. This 
means you trade off better hardware and software price performance against 
systems improvement. 
0 - (Thomas to panel): What about before and after performance audits of 
systems? 

il. — (Vaughan): Although this is desirable theoretically, a more important 
consideration in new systems today is provision for future expansion. The 
machine efficiency which was so Important in second generation systems has 
now been eclipsed by people costs of system maintenance and revision. You 
can save real dollars by giving up some efficiency for more generalized 
design. 

- (from audience): When you are data rich and systems poor, how do you 
handle data standardization? From the top of the organization down, or 
the bottom up? 

yi. • (Scott): Systems design activity tends to bring this problem to the surface; 
o 



if It can be solved at the working level fine, but In some cases, parti- 
cularly where system Integration across organizational lines Is planned, 
» fairly high levels of management may have to get Involved. 

(Roberts): In working with applications for OASIS, we found that an 
anticipated major expansion of data for management "needs" never material- 
ized. If you design a good operating level system, it is likely to hold 

almost all the information necessary to support managerial analysis and 
decision needs. 

Q, - (from audience): Is it cheaper to standardize data elements as you go 

or to try to convert the whole system? 
A» - (Scott): Try to standardize just at the point in time where a major issue 

arises. You can create a great deal of unity in a short time if you pick 

the right time for standardization. 

(Roberts) : One idea we have used where only some codes in a master file 
need changing, is to put the file up (using OASIS), and make the changes as 
part of the first use of the new system. This can save a lot of time and 
irritation in trying to get into the old file to make changes. 

a - (from audience): How do you feel about attempting to tap expertise on 
the part of the faculty? 

A. - (Roberts): At Stanford we cannot compensate faculty for helping beyond 
their academic salaries. This puts us in a difficult situation vis a vis 
the ability of faculty members to accept consulting fees from outside 
organizations. Faculty committees are not much help either, because of 
infrequent meetings and crowded agendas. 

(audience): Graduate students are a good source of Inexpensive talent. 
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Appendix IV -Application Development Methodology 

A project structure has been developed called DIP (Design and 
X^'plementatlon Plan) which specifies the various steps and require- 
ments of a sySitems project. The objectives of the plan are to: 

. Provide a consistent approach to solving systems problems 

. Detail the organization and content of system documentation 

. Produce documentation as a by-product of development effort 

• Facilitate transfer of maintenance between SDG staff members 

In this project approach, the user Is directly Involved in the creation 
of systems which eventually will support his functional area. Use of 
DIP promotes i:ar cooperation, and establishes user responsibility 
for realizing benefits forecast fur each system. Thus all users be- 
come Involved in cost management for projects. 

Structuring each project also aids communications and working 
discipline. At each stage, management presentations, review, and de- 
cisions are based on Increasing knowledge about the system and on 
greater certainty of costs and benefits. Units of work are under- 
taken and controlled in 'chewable bites', and management commits the 
technical staff to accomplish specific pieces of work at established 
checkpoints. 

When a project reaches the point of intensive technical develop- 
ment, programming, and development of user training, management Is 
carried forward on an exception basis. Before the project's major 
technical activities are started, objectives are specified and re- 
sources are allocated* As long as the project remains within the 
bounds of these objectives, management need not be brought Into the 
pictfire for technical details. But by the time a project reaches this 
stage, its feasibility has been thoroughly established, as has close 
understanding between users and SDG staff. 

As part of the technical specification activity of a system 
project, standard activities and estimated times are established for 
the processing of jobs. In arriving at these performance estimates, 
the computer facility manager and key members of his staff become part 
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FIGURE IV-1: Design and Implementation Plan 




of the system project team in much the same way that the user does in 
establishing system objectives and identifying potential benefits. In 
the case of standard activities and estimated times for computer jobs» 
schedules and routines are subject to adjustment when the work is 
operational in much the same manner in which standards are revised for 
manufacturing jobs after a product is in production. However, it is 
basic to the project technique that processing costs be estimated 
closely before the system Is implemented. 

As indicated in Figure IV-1 (preceding page), the Design and Imple- 
mentation Plan is organized into five phases which ensure an orderly 
progression in the development and implementation of a system over 
a period of time. 

Phase 1 » Request/Proposal : A potential need for computer service 
arises, and this potential need is discussei by the user and an analyst 
assigned by SDG. When these preliminary discussions establish that the 
need appears feasible to meet with a computer system, SDG assigns a 
project number and a project leader to the request. All further de- 
velopment work is performed under this number, and all documents 
refer to it. 

The project leader and the user then detail the definition, re- 
quirements, objectives, justification, priority, and environment of 
the problem. The project leader analyzes the various methods which 
could be utilized to solve the problem, estimates costs of each, and 
selects the one he feels is best suited. These details comprise a 
"proposal" which is first subjected to internal review and then pre- 
sented to the user. 

If the proposal is accepted, the project leader is authorized to 
develop functional specifications for the project: 

Phase 2, Functional Requirements ; The proposal is used to de- 
velop functional specifications which describe in detail the method 
to be used in meeting the objectives of the proposal. The project 
leader prepares these specifications in close cooperation with the 
user. 

They are then submitted for approval. If approved, the project 
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leader is authorized to proceed with more detailed specifications. 

Phase 3t System Specifications ; The approved functional specifi- 
cations provide the framework for design of the system. The SD6 project 
leader identifies logically related processes within the system and, 
using this information, designs system and program specifications. The 
design considers the restraints of timing, processing requirements, 
costs, and effective computer utilization. As the system specifications 
are developed, procedures for using the system are provided to the 
groups responsible for its use and operation* 

Upon approval of this phase, the design is frozen. That is, 
changes tD the approved system wi'.l not be made without considering 
their impact on the cost and implementation schedule of the system. 
Changes which are considered desirable but not necessary for the 
implementation are documented and filed in the system "Wishbook*" 

Phase 4, System Impleriientatlon and Operation ; Programs are 
written and tested. Complete Instructions for producing the system 
outputs are prepared and given to computer operations staff. These 
include scheduling, operating, controlling, output handling, and 
delivery* Any necessary file conversions are performed, and a parallel 
test is made. A final estimate of production cost is made. 

The user reviews the results of the parallel test and the final 
cost estimate* If he is satisfied with these, the system becomes 
fully operational • 

Phase 5, System Performance and Evaluation : Within three to six 
months after implementation, an appraisal is made of the performance 
of the system In meeting the objectives set forth during the original 
definition of requirements phase. If the performance fails to meet the 
design objectives, appropriate changes will be made before the system 
is released to routine production* The evaluation should also measure 
the actual cost of development compared to the planned cost for, his- 
torical purposes and for the benefit of those managing the project. 

At this time, the project is considered complete. 



Appendix V - Background Note on Project INFO and OASIS 

In the spring of 1968, the Ford Foundation granted Stanford 
University $700,000 to be used over three years to support the work of 
Project INFO (Information Network for Operations) in the design and 
testing of an integrated computer system for university administration. 
Previous studies had shown that at Stanford, as well as at many other 
universities, (1) the full capabilities of computer equipment and pro- 
grams were not being utilized to support the needs of administrative 
offices and top management;, and (2) computer support was becoming more 
and mire critical to successful operation of the institutions. Although 
the problems leading to this situation were numerous, Stanford felt 
that most could be solved if given a substantial commitment of resources 
to perform the necessary design and development tasks. The University 
was particularly anxious to proceed with the project because a number 
of years of substantial investment in administrative computing had 
already produced major Improvements in several areas, particularly 
alumni development and financial management. Even though these improve- 
ments were significant, the demands of management for support had out- 
run the capability of the computer and systems then in use. During 
1966-67, a five-man study team was formed to investigate the require- 
ments for broader and more comprehensive administrative computer support, 
and to analyze the system features necessary to meet them. The planning 
document which resulted from the study concluded that an integrated 
system was feasible within the limitations of third generation computer 
technology and delineated the following major requirements for such 
a system: ^ 

(1) A single machine file of computer readable data combining 
existing independent computer and manual files, 

(2) a logical file structure which allowed data definition and 
retrieval independent from its physical representation or location in 
the machine file, 

(3) remote terminal access to files and processing programs, and 

(4) a generalized inquiry and report generation capability to 
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handle management oriented* non-routine needs for information* 

Although feasible, the creation of such a system required answers 
to many technical computer systems questions that only Intensive study 
could provide* Further, it was Impossible to determine the specific 
operating costs of such a system in advance, and this would clearly 
have a major Impact on Its effectiveness in financially hard pressed 
colleges and universities. Taking these and other considerations Into 
account, Stanford initiated a proposal for development of such a system 
and requested assistance from the Ford Foundation. Specifically, 
Stanford proposed a full scale pilot study to design and test such a 
system, to develop guidelines and techniques for Its use, and to dis- 
seminate the results of the study widely to Institutions of higher 
education. Although the system was designed to support all administra- 
tive computer requirements, it was considered essential to concentrate 
effort Initially In those areas which most acutely needed support at 
Stanford and which also had a major impact on the flow of university 
resources. Accordingly, the proposal assigned priority to development 
of systems for Student Services, Alumni , Personnel , Accounting, Pur- 
chasing, and Institutional Self Study. 

Following the grant award, a project team was formed and rapid 
progress was made toward development of specific design approaches to 
an integrated system. An evaluation was begun to determine whether 
any existing data management system could provide the breadth of support 
sought within the proposed computer configuration. On a parallel basis, 
wo***i proceeded to define the data base* requirements of the different 
application areas. 

As the data management system evaluation effort proceeded, it be- 
came apparent that there was a basic dichotomy in the systems being 



*A large computer file of information is usually referred to as a 
''data base", carrying the connotation that It contains all necessary In- 
formation to perform specified processing and reporting requirements. 
An integrated file scheme such as that adopted by Project INFO is also 
commonly known as the "data base approach" to systems design. 



sufveyed. Those which were able to operate on medium sized computers 
such as might be expected to be available to university administrators 
lacked sufficient capability to support the INFO design objectives, and 
those systems which did meet the objectives contained many features 
which were superfluous to the needs of university administration and 
resulted in machine requirements which the INFO staff considered to be 
beyond the reach of all hut a few schools. This discovery had a funda- 
mental impact on the subsequent course of the project during the grant 
period because it led to the decision to design a new data management 
system tailored to the specific requirements of the university admini- 
strative environment and to the general economic constraints operating 
in that environment* Subsequent to the completion of the design, a 
major software development effort was 1n1tiat*fed to write and test the 
programs necessary to implement the design in an operational system. 
This effort, which required allocation of the greater part of project 
resources during 1969 and 1970, produced OASIS (Online Administrative 
Information System)* 

In OASIS, data is stored on a random access disc device in a manner 
which allows sequential processing to meet volume output requirements. 
In addition, the data base has multiple access points to facilitate 
random retrieval and maintenance. Security of confidential information 
is maintained at the data element level as well as at the higher segment, 
record, and file levels. 

Online video terminal support includes both tailored and general 
services. The tailored services consist of COBOL or Assembly language 
application programs created for specific office functions. Two general 
services, Query and Report Generator, permit file inquiry and the 
quick specification and production of reports. 

The heart of the system is the OASIS file service which accepts 
requests from higher level programs and translates them into detailed 
manipulations of the data base. Requests can refer to data items by 
name, without regard to their location within a record, providing a high 
degree of disengagement from data base layout. It 1s thus possible to 
deal with the data logically without regard to record organization. 
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The concept of the '^totaV system described in the original INFO 
proposal has been Implemented in OASIS by providing for standard physical 
representation of data in the computer files, and for uniform methods of 
inserting* removing, and changing data. Although OASIS handles all data 
presented to 1t in the same way, the system Is structured to provide for 
the logical integrity and security of data according to the specific 
requirements of administrative users* Each user controls his own data 
base and retains responsibility for its validity, but the system treats 
all data identically from a machine standpoint. Through a system of 
data dictionaries, a user has access not only to his data, but also to 
that of any other user to which he has been granted access. 

Following successful testing of the prototype version of OASIS In 
the Fall of 1970, development of designs for use of the system in 
the Student, Alumni/Gift, and Employee areas was accelerated, and plans 
were adopted for conversion of existing manual and computer systems In 
these areas to OASIS. Detailed information on functional capabilities 
of the new designs is contained in Section 2 of this report. 

By the summer of 1971, nearing the end of the Initial three year- 
grant period, many project objectives, particularly those relating to 
design and development of an integrated computer system had been achieved. 
However, OASIS was- -still not in production use at Stanford, and was under 
test at only one other computer installation. Additional funds were 
requested from the Ford Foundation to assist in completion of four major 
applications at Stanford, to study and evaluate the performance of the 
system in operation, and to continue to support the use of OASIS at 
other institutions. A renewal grant award of $190,000 for two years 
through August, 1973, are as follows: 



Task Description 



Estimated Han-months 
of Effort 



Complete Development of Student System 
Complete Development of Alumni/Gift System 
Complete Development of Employee System 
Develop Budget System 
Support OASIS Development and Maintenance 
Support OASIS Installation at Other Institutions 
Study OASIS Performance 



48 
36 
60 
48 
48 
24 
1^ 



Appendix VI - OASIS Data Element Dictionaries 

The following pages contain data element dictionaries for three 
OASIS applications now under development at Stanford - Student, Alumni/* 
Gift* and Employee. The elements and their definitions are those which 
presently appear to be necessary to meet operational and analysis require- 
ments of users* and are subject to future change as the systems go into 
production and are evaluated. 

The OASIS file structure requires that data be defined at the re- 
cord, segment, and data element levels. Data elements are of fixed 
length. Segment definitions specify a fixed length, but up to 255 
different segment types may be defined, each of a different length if 
desired. Records are composed of defined numbers of segments, which may 
or may not be actually present in the record. This method produces 
a significant reduction in file size requirements over conventional 
fixed length record schemes without incurring the overhead of full 
variable length treatment of data. 

In the dictionaries, data elements are shown in order within the 
segments in which they are defined. Segments are shown in the order in 
which they appear in each record. The data element names are those used 
in OASIS Generalized Services and appl icatioiti networks for retrieval 
and update purposes. Elements for which it is planned to create separate 
value Index tables to facilitate rapid retrieval are shown with a "Y" 
in the right hand column. 

The 1 ength of each data element in bytes (eight bits) is Indicated. 
The physical representation of the data in the online file is shown 
according to the following type descriptions: 
B = Binary 
C = Character 
Z - Zoned Decimal 
P « Packed Decimal 

The choice of type foi;* each data element is usually a result of 
study of processing requirements, particularly the extent of the need 
for arithmetfc manipulation. 
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OASIS MTA ELEMENT DICTIONARY - STUDENT FILE 



sso 

EL EH NO. 

',1 ■ 


ELEMENT 

NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES] 


INDEXED 


■■ * 1 : 




Segment I, CJ^Uxining haHo identifi<iation data, oq<3wp3 cnae pet* 
student. It ie qne of three required eegmente, the o there being 
eegmente 1$ and 14B. 








1.1 


HEH8ER.ID 


Ten position Student Identification. Uniquely identifies the student 
1n the OASIS Student file. It Is formatted as follows: 

u - {411 - NNNiirirf wnere 
0 - always tero for ID future expansion 
QYY • Matriculation QYY (Quarter and Year) 
nnnnnn ^cnaiiy sssigneo nuniDer 


c 


10 


Y 




MEMBER. NAME 


Student's nafw formatted: Last, First, Middle 


c 


23 


Y 


1.4 


SEX. CODE 


Twf) I/aIiIPC* M « Ma 1a XnA r a PAm^lA 

1 wv vaiuca* n noic any r rciDalc 


c 


1 




1.5 


MARITAL. STATUS 


Two values: M « Married and S « Single 


c 


1 




1.6 


BIRTH. DATE 


Date of Birth - Format: Year> Month, Day 

rorntai uispiay: nontn, uay> Year 


c 


6 




1.7 


DATE. LAST. TRANS 


Date last time the student record had activity. 
File Format: Year, Month, Day 
Display Formatt Month, Day, Year 


p 


6 




1.8 


NAME. TYPE 


Forniat of Name. One format for all student records. 
Code 0 « Last, First, Middle 


c 


1 




1.10 


RECORD. TYPE 


One value - S. All students that are on the file. 


c 


1 




1.11 


UPD. ACTIVITY 


Indicates latest type of activity on a particular student. 


c 


1 








Reeer\>ed for future use. 








4 




An optional segment containing infomxtion about special namee* 








4.1 


PREFERRED. NAME 


Legal Name - for names longer than 23 positions. 


c 


30 




5 




An optional recurring eegment containing information about prior 
namee. 








5.1 


OTHER. NAME 


Maiden t\Atn^ 








5.2 


OTHER. TYPE 


Same as 1.8 -> one code only 0. 


c 


1 




5.4 


OTHER. NAME. CODE 


Value = 1 for Maiden Name. 


c 


1 




5.5 


OTHER, NAME. OATE 


Format: Year, Month, Date name changed. 


c 


4 




€ 




An optional segment containing infomation about parent or guardian^ 








6.1 


GUARDIAN. NAME 


Name of parent/guardian. Format: Last name. First, Middle, suffix. 


c 


23 




? 




An optional eegment pertaining to emergency contact. 








7.1 


EMERG.NAME 


Emergency party name. Format: Last Name, First, Middle, suffix. 


c 


23 




8*10 




ncoff*\^a* J or jl4irUJ*e Uavt 








11 




An optional recurring eegment containing infomation on local addreee. 








11.1 


LOCL.ADDR 


Local Address - Street Number and Name and Apt. Number or Residence 
Hall and Room Number. Only one occurrence can be input. 


c 


24 




n 




An optional eegment about local city. 








12.1 


SPEC. CITY. 1 


Local City Name. One element optional segment. 


c 


19 





OASIS DATA ELEMENT DICTIONARY - STUDENT FILE 



$so no. 

ELEH NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 






One of three required eegmente for each etudent'e record* 








13 


2IP.1 


Local ZIP code - zeros If ZIP co<Je Is unknown. 


C 


5 








Reserved for future uee* 












A one element optional eegmente 








15.} 


TEL. NO. 1 


Local Telephone Number. 


P 


7 








Reserved for future use. 








22 




A OYI& fiZtzmj>Kt, ontifiti/il t*fi/*ur*y^iyin o^r/rrt^ri^ 








21.1 


HOHE.ADDft 


Hone Address Street Location. A one element optional recurring 
segment. Only one occurrence can be Input* 


C 


24 




B3 




An optional recurring segment containing Home City and Home State, 
One occurrence (line) is permitted as input. 








22.1 


SPEC.CITY.2 


Home City. 


C 


19 




22.2 


ST. CODE. 2 


Home state - 2 positions {official postal service abbreviations) 


C 


2 








Optional segment containing two elemnta only one of which is used. 








23.1 


ZIP. 2 


Home Address ZIP Code. 


C 


5 




24 




A one element optional segment. 








<4.1 


TEL .AREA. CODE . 2 


Home Telephone Area Code. 


P 


3 




25 




A one element optional segment. 








25.1 


TEL. NO. 2 


Home Telephone Number. 


P 


7 








Reserved for future use* 








31 




t\ vTve V tfVf'icrnr vu^ieWTWiff I vviAx^wfig ovgfiivTiv wnere ontu one occurrence 
can be pemitted as input. 








31.1 


GARO. ADDR 


Parent/Guardian Address - Street Location. 


C 


24 




32 




A two element optional recurring segment where only one occurrence 
can he input. 








32.1 


SPEC. CITY. 3 


Parent/Guardian City. 


c 


19 




32.3 


ST. CODE. 3 


Parent/Guardian State • 2 positions (official postal service abbrev.) 


c 


2 




•* 




An optional segment containing two elements only one of which is used. 








33J 


ZIP. 3 


ZIP code of Parent/Guardian Address. 


c 


5 




S4 




A one element optional segment. 








34.1 


TEL. AREA. CODE. 3 


Parent/Guardian Telephone Area Code. 


p 


3 





ERIC 
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tNDEXCD 


36 




A one element optional 6egment» 








35.1 


TEL. NO. 3 


Telephone Number of Pa rent/Guard fan. 


p 


7 




36^40 




Reeetved fof futux*e uee. 












A one element optional reourHng segments 








41.1 


EMR6.ADDR 


Enieraencv Partv Street Address. Qnlv onp orrurrpnrA npnnlttp^ ;i< 
as Input. 


V 


c^ 




it 




A two element optional veourHng eegment tJiere only one ooourrenoe 
ie u8e<i» 








42. 1 


SPEC. CITY. 4 


City Name of Emergency Party Address. 


C 


19 




42.2 


ST. CODE .4 


State abbreviation of Emergency Party Address. 


c 


2 




il 




An optional eegment of Z elemente only one of whiah ia ueed» 








43.1 


IIP. 4 


ZIP Code of Emergency Party Address. 


c 


5 




ii 




A one element optional eegment^ 








44.1 


TEL. AREA. CODE. 4 


Area Code of TeleoKone Number for Tmeraenrv P^rtv Addrpss 


p 

r 


<j 




ih 




A one element optional segments 








4S.1 


TEL. NO. 4 


Telephone Number of Emergency Party Address. If Stanford extension, 

first thrpp dialts are 0{)0 Uhpn di<r^^n^/oei/r\rinfoA TKT will Ka: hcaH 


P 


7 




4$^ 4$ 




t\voewe<x J or juvtij^e uoct 








SO 




A one element optional eegment», 








50.1 


BOX. NO. STANFORD 


University Post Office Box Number. Usually used by students living 
In residences where mall cannot be delivered. 


c 


4 




51-53 




Reserved for future itse. 








S4 




An optional segment containing Address SimiliaHty indioatore. 








54.1 


H.SIM 


Home * Local. Code ■ L. 


c 


1 




54.2 


G.SIM 


Parent/Guardian « Local or Home. Code » L or H. 
or « Local & Home. Code « L. 




1 




54.3 


E.SIM 


Emergency « Local or Home or Parent. Code « L,H»P. 
or « Local & Home. Code » L. 
or e Local & Parent. Code > L. 
or « Home and Parent. Code * H. 


c 


1 








Reserved for future use> 








71 




An optional recurring segment sienarizing aoademia achievements to 
be used for Almni Records » 








71.1 


AGO. LEVEL 


Academic achievement level upon leaving Stanford. Not used by the 
Registrar's Office. 


c 


1 




71.2 


AGO. SCHOOL 


School to which student belonged upon leaving Stanford. 


c 


1 
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STUDENT FILE 
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(BYTES) 


INDEXED 


71.3 


ACO. MAJOR 


Major of student upoo 1eav1n9 Stanford. 


C 


3 




71.4 


ACO.YEAR 


Calendar year 1n which student left Stanford, 


C 


4 




7K5 


ACD,DEG,QTRS 


Degree Code or Number of quarters a student stayed In above major 
upon leaving Stanford. 


C 


3 




71,6 


ACD.ACK.QTR 


Quarter (Fall, Wtnter> Spring^ or SunvDer) that a student left Stanford. 


C 


1 








Reaepved for future use. 








74 




An opt'frOYial reourHng segment containing one occurrence for each 
reeiience where etudent teved. 








HA 


RESIDENCE. CODE 


All residence codes of Residence Walls in whkh student lived while 
attending Stanford. The last occurrence Indicates his latest resi- 
dence code (the current residence code If he Is currently registered). 


P 


3 




74.2 


QYY. RESIDED 


Date in Quarter and Year format (QYY) in which the student lived at 
the residence. 


P 


3 




75-141 




Reserved for future use. 








142 




One of three required segments which must occur only once. It contains 
latest academic and registration status. 








142,1 


MAJOR 


3-d1git code» the left most is the school. Major codes In Table 101; 
School Codes in Table 102. 




3 


Y 


142.2 


AR.FLAG 


Values: A - Advance Registered 

0 - Registered on Reg Day 




1 


Y 


142.3 


LQR 


Last quarter, in QYY format, In which the student registered, 




3 


Y 


142.4 


CLASS 


Academic Class - ^1 - Freshman 
2, - Sophomore 
etc. Codes in Table 103. 




1 


Y 


142.5 


ACT. RIG 


Religious Activity indicator. 




1 




142.6 


RPREF 


Religious Preference. Codes in Table lOS. 




2 




142.7 


DEGREE. CAND 


Code that indicates if student applied for a degree • 
8 - Undergraduate Degree 
G - Graduate Degree 




1 




142.8 


FUTURE. REG. PLANS 


Indicates in which future quarter student Intends to register. Codes 
in Table 106. 




1 


Y 


142.9 


ADV. CODE 


Advisor Code for student whose major is undeclared. 




2 


Y 


142.10 




trant» etc. Codes in Table 107. 




c 


V 

f 


142,11 


REG. TYPE 


Indicator • 1 • Old Returning 3 ■ New Student 

2 e Continuing 4 » None of the above 


c 


1 


Y 


142,12 


CLASS.ORG 


Indicates initial adniission class. 




1 




142.13 


HOLD, IND 


Indicates if any hold notices exist for this student. Holding depart- 
ment codes are In a separate recurring segment. 




1 




14$ 




Optional segment containing country of citizenehip. All foreign 
students ix^uld have this segment as part of their record on the 
OASIS Student File, 








143.1 


COUNTRY. CODE 


Indicates country of c1ti2ensh1p for foreign students. 


p 


3 


Y 




OASIS DATA ELEMENT DICTIONARY - STUDENT FILE 



SSO HO* 
£L£H N0« 


ELEMENT 
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DATA 
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LENGTH 
(BYTES) 


INDEXED 


143.2 


VISA. TYPE 


Under what basis student entered U.S. * foreign students only. 




1 








An optional recurring Qegrnent containing hiatory of prior naJo:'e, 
On0 occurrence per mjor* 








M4.I 


QVy.PR.MAJ 


Date of previous School and Major enrollment In QYY format. 




3 




144.2 


MA J. PR 


Previous School and Major 1n which student was enrolled. 


c 


3 




m 




An optional recurring eegfnent that contains eunnary fee infotwition* 
One ooourrenoe per quarter » 








14S.) 


TCODE 


Tuition code for a specific quarter. 




2 


Y 


14S.2 


AHT. TUITION 


Assessment or Payment Amount of Tuition. 




4 




145.3 


RES.CODC 


Residence Kail code where student Ijlves on campus. Off campus resi- 
dents are coded 000. 

i 




3 




MS.4 


RENT. ROOM 


Rent Charges for above residence code. 




3 




145.5 


PLAN. BOARD 


Code for one of several Board Plans offered by Food Services. 


c 


1 




145.6 


BRD.FEE 


Cost of Board Plan per quarter. 




3 




145.7 


A0D.CH6.CD 


One of several combination codes reflecting type of other charges. 




2 




145.8 


AMT.OTH 


Total amount of other charges. 




3 




145.9 


LATE. FEE 


Late Fee charges. 


p 


3 




145.10 


CASK 


Amount of net cash for a specific quarter paid by student. Includes 
Z decimal positions. 




6 




145.11 


GRANTS 


Net amount of total grants awarded to student for a specific quarter. 
Carried to 2 decimal places* 




6 




145.12 


DEFERRED 


Net amount deferred per quarter carried to 2 decimal positions. 


p 


6 




145.13 


DATE. TRANS 


Date of latest fee transaction for a specific quarter* Format Is 
Year, Month, and Day. 




6 




145.14 


QYV.FEE 


Date Is QYY format for which fees apply. 


•* 


3 




145.15 


6ATCH.no 


Batch Number of latest Fee transaction that updated this quarterly 
activity. 




3 


Y 


145.16 


DUES.H 


House Dues. 


p 


3 




lis 




An optional recurx*ing eegfnent containing detail tz^xneactione* One 
occurrence per transact ion. 








146.1 


TCODE. D 


Detail activity Tuition Code can occur, more than once per quarter » 
as many times as It changes. 




2 




146.2 


AMT. TUITION. 0 


Amount of tuition paid * detail activity. 


p 


4 




146.3 


RES. CODE. D 


Residence Code changes activity within a qaurter. 




3 


Y 


146.4 


RENT. ROOM. D 


Room charges activity. 




3 




146.5 


PLAN.80AR0.D 


Board plan changes activity. 




1 




146.6 


BRO.FEE.D^ 


Boarding Fee detail activity. 




3 




146.7 


ADD.CHG.CD.D 


Detail activity of additional charges. 




2 




146.8 


AMT.OTH.O 


Detail activity of amount charged for additional charges code. 




3 

i 
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146.9 


LATE. FEE. D 


Late Fees. 


P 


3 




146.10 


CASH.D 


Cash paid to cashier as a result of a Fee transaction. 


P 


6 




1 AC 11 

146. 1 1 




Grants-fn-aid anx>unt*-detail activity within a quarter. Reflects 
total amount of various grants. 


P 


6 




146.12 


DEFERRED. 0 


Deferment Amount Activity. 


f> 


6 




146.13 


CHANGE. RET. D 


Change returned by cashier after a fee transaction Is handled. Usually 
student pays iTK>re fees than assessed so that he can have some chan9e 
returned In cash. 


P 


6 




146.14 


REFUND. 0 


Refunds by cashier due to a tultfon reduction. Usually happens after 
registration activities. 


P 


6 




146. IS 


DATE .TRANS. 0 


Transaction date—Format: Year* Month, Day. 


P 


6 




146.16 


QYY.DEE.D 


Date in QYY format for which this Fee transaction applies. 


P 


3 


Y 


146.17 


BATCH. NO. D 


Batch No. to which fee transaction belonged. 


P 


3 


Y 


Hp. Id 


AD Id 

UdN 


Old batch number for control purposes. 


t% 
r 


3 




146.19 


DUES . H.O. 


House Dues detail . 


P 


3 




U? 




An optional segment indicating place of birth* 








147.1 


8IRTH. LOCATION 


Indicates place of birth. A one elernent optional segment. 


c 


24 




148 




An optional segment that occurs for students living on campus. 








148.1 


QYY.RES 


Effective date of residence In QYY format. 


p 


3 




14d.2 


NICK. NAME 


Used by housing office as all elements of this segment are. 


c 


12 




148.3 


RES.LST 


Previous res1dence--for control purposes when updating. 


p 


3 




148.4 


RES. CUR 


Current Residence Code. Codes and Rates In Table 112. 


p 


3 


Y 


148.5 


ROOM. NO 


Room number. 


c 


4 




148.6 


8ILL.C0DE 


Used In conjunction with Residence code to modify bills for some 
students. 


c 


1 




148.7 


PLAN.B 


Board plan selected by student. 


c 


1 




148.8 


DPST.NO 


Used by housing office for control purposes. 


p 


6 




li$-SO 




For future use. An unused optional eegment defined as one element. 








ISl 




A recurring segment that contains the cumulative courses taken by 
a student. 








151,1 


QYY.CRSE 


Date, in QYY format, a course is taken. 




3 




151.2 


CRSE.SC 


9 posttfofi field that does Include Dept. Number, Course Number, Suffix, 
and Section-- Format xxx xxx x xx. 




9 


Y 


151.3 


UNITS 


Credit Units. 




2 




151.4 


GRADE 


Grade Earned. 




2 




151.5 


RQYY 


Quarter and Year (QYY format) in which a grade Is revised. 




3 




151.6 


OGRADE 


Original grade. 




2 





ERIC 
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164 




An optional eegment that contains Bvfnmry credit u«ita. 








154J 


QUP 


Last Quarter's Units Passed. 


P 


3 


Y 


154.2 


UTG 


Units towards graduatlon^'used only for Undergraduates and co*termina1 

ctuHpnfc fnrliiHfie linffc Trjincf ArirAH 


P 


3 


Y 


VS4.3 


LGU 


Cumulative units for courses with grades A, 6i d D. 


P 


3 




154.4 


L6I 


Cumulative-Letter Grade Ind1cator»«for possible future use. Format 
7.79 ^Siniiiar vo uraae roint MVcroge/* 


P 


3 








non*3tanToro units rassxo^ 'ransTcrreu Trwn ariotficr scnooi. 


D 

r 






ISS 




A eegtnent tHth only one pcdeihle o<^ourrenoe used to reoord Admieaion 
dcttcL about und^v^fcducitcd* 








1 9v. 1 




nign ocnQoi or Loiiegc insiituvion i^ooe lor enberiiig rresnmen anxi 
Transfers. , 








155.2 


MAJ.TR 


Prior School and Major Code In which transfer student was enrolled. 


c 


3 




155.3 


TVPE 


Type of Institution from where student came. Public or Private. 


c 


1 




155.4 


GPA.TR 


Prior GPA (orequlvalent of GPA) of Transfer student. 


p 


3 




155.5 


CTy.HS 


Usually reflects the county of residence. 


p 


3 




155.6 


VRB.SAT 


SAT Verbal Score. 


p 


3 




155.7 


MATH* SAT 


SAT Math Score. 


p 


3 




Joo 




An opttonot B&grn^nt that contctiKB AdirtiBBion Infox^natton about cnteiH^n^ 
Gt^dnatee, One ocaurrenoe per each previoue institution attended, 








156.1 


INST. CODE. COLLGE 


Institution Code—first two positions blank. 


c 


6 




1 7v.£ 


MAJ.C 


rmjur uv prcYiuus iriabibUwiuii. 


r 


'> 




1 1 

1 3v • V 


APA r 


\irn or ecfUiVaieriv ai previous i^oiiege or univcrsiby. 


D 

r 








r 


^11 in wniLfi a oLariTora unvjcryr aaua lc aLarbcu mis graauovc wurK. 


p 

r 










uei^rcc uuvoinca irori prior iiisli luvion. 


V 


J 




156.6 


MVy.DEG 


Date degree obtained In Month (1 position) ard Year format* 


c 


3 




257 












157.1 


VRS.G 


GRE Verbal Score. 


c 


3 




157.2 


QNT.G 


GRE Quantitative Score. 


c 


3 




157.3 


AA.6 


GRE Advanced Area Code. 


c 


3 




157.4 


SCR.AA.G 


GRE Advanced Area Score. 


c 


3 




1S8 




A one element optional eegment. 








mA 


ORIG. STUDENT. ID 


Original Student ID-S positions. A one element optional segment used 
for conversion Into the Student System. 


c 


a 


y 


11$ 




A one element optional recurring segment. 








159.1 


TR. COMMENTS 


Comments to be printed on Transcript. Can have more than one line. A 
one element optional recurring segment. 


c 


46 





ERIC 
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2 SO 




A one element optional reaurHng eegment. 








160.1 


GEN. COMMENTS 


General connents not used for Transcripts. A one element optional 
recurring segment. 


C 


46 




161 
W 




An optional r^aurrCng segment that {ficti4de'i the etudent'e oouteed 
taken for Fall Qtr, 








161.1 


QYY.CRSE.l 


Oate In QYY format a course was taker. This Is always Fall Qtr for 
any year» 




3 




161.2 


CRSE.SC.1 


See 151.2-CRSE.SC (Dept. Number, Course Number, Suffix, Section). 




9 


Y 


161.3 


LINE , 1 


Used internflllv (hv a Dr(\QrPttn\ tn urvfAtP flr;i<4p( I fnp numhpr nf a 

Student on a class list. 




C 




161.4 


SQ.l 


Usage same as LINE.l Page Number for a specific course or a class list 




2 




161.5 


UNITS. 1 


Credit Units 




2 




161.6 


GRAOt.l 


Grade posted on class list. 




2 




161 < 7 


RQYY.l 


Quarter and Year in which original gratfo was revised. 




3 




161.8 


OGRAOE.l 


Original grade. 




2 




162 




Same definition ae segment 161^ hut fot* Winter Quarter Couraee. 








162.1 


QYY,CRSE.2 


Soe 1 61 . 1 




3 




162.2 


CRSE.SC.2 


See 151.2-Oept. Number, Course Number, Suffix and Section. 


c 


9 


Y 


162.3 


LINE. 2 


See 161.3 




2 




162.4 


SQ.2 


See 161.4 




2 




162.5 


UNITS. 2 


See 161.5 




2 




162.6 


6RA0E.2 


See 161.6 




2 




162.7 


RQYY.a 


See 161.7 




3 




162.8 


0GRADE.2 


See 161.8 




2 




m 




Sane definition as segment 16 2 , hut for Spring Quarter Courses, 








163.1 


QYY.CRSE.3 


See 161.1 




3 




163.2 


CRSE.SC.3 


See 151.2-Dept. Number, Course Number, Suffix, Section. 


c 


9 


Y 


163.3 


LINE. 3 


See 161.3 




2 




163.4 


SQ.3 


See 161.4 




2 




163.5 


UNITS. 3 


See 161.5 




2 




163.6 


GRADE . 3 


See 161,6 




2 




163.7 


RQyY.3 


See 161.7 




3 




163.8 


0GRA0E.3 


See 161,8 




2 




264 




Satne definition ae eegnent 161, but for Sumer Quarter Coureee, 








164.1 


QYY,CRSE.4 


See 161 1 




3 




164,2 


CRSE,SC,4 


See 151.2-Oept. Number, Course Number, Suffix, Sectfon. 




9 


Y 


o 
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164.3 


LINE. 4 


See 161.3 


C 


2 




164.4 


SO. 4 


See 161.4 


C 


2 




164. S 


UNITS. 4 


See 161.6 


Z 


2 




164.6 


GRADE. 4 


See 161.6 


C 


2 




164.; 


RQYY.4 


See 161.7 


P 


3 




164.8 


0GKADC.4 


See 161.8 


C 


2 




les 




Scone definition ae segment 161^ but for temporary etcrage. 








165,1 


QYY»CRSE.5 


See 161.1 


c 


3 




16S.2 


CRSE.SC.S 


See 151,2-Oept. Number. Course Number, Suffix, Section. 


c 




Y 


165.3 


LINE.S 


See 161.3 


c 


Z 




165.4 


SQ.S 


See 161.4 


c 


2 




16S.S 


UNITS. S 


See 161 .6 


I 


2 




165.6 


GRADE. S 


See 161.6 


c 


2 




16S.7 


RQYY.S 


See 161.7 


p 


3 




16S.8 


OGRADE.S 


See 161,8 


c 


2 








An optional reourrtng aegrftent used to contain infomation about 
Holding Departments » 








170.1 


DPT. HOLDING 


Code of Department placing a hold on Registration. 


c 


3 


y 


170.2 


AHT.DUE 


Amount due If any. 


p 


7 





ERIC 
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tun m. 


EUKENT 

mt 


DESCRIPTION 


DATA 

TVDr 

1 Trt 


LENGTH 


INDEXEG 


t 




Segment t ooaura once pet' memfcer. It oontaine haeio data Buoh 
as Nam and Xdentifioation» 








1 « 1 


ur lib CD t n 


nefnoer Nurroer. 


C 


10 






ALUH.1D 


Seven position number, tncludlng check digit that redefines 
MEMBER. 10, 


C 


7 


y 


1 .c 


MENoER. NAME 


Name of member; formatted according to the code shown in NAME. TYPE 
(element 1 .8). 


c 


23 






HEM. NAME 


Twelve position field redefining member. 


C 


'i 


Y 


1.3 


MEMBER. TVPE. IN 
ntMDt K . I YPt .UN 


Name for Indexing description of the type of mefl^ber this member 
name and number 'represent. Excludes Value M'. 

Same as 1,3» includes all Values, 


c 
c 


1 


y 


1 A 


St A .CODE 


A coce describing member's sex. 


c 






% r 

1 .9 


MARl TAL . STATUS 


A code designating marital status of member. 


c 






1.6 


BIRTH. DATE 


Birthdate of member when it is known. 


c 






1.7 


LAST, TRANS, DATE 


Day of the update on which a change was made to member's record. 


p 






1.8 


NAME, TYPE 


Format code of a member name governing access and printing. 


c 






1.9 


TITLE, CODE 


Title codes for Hr., Mrs., Miss, Dr., Ms. 


c 






KIO 


RECORD. TYPE 


Indicates member Is fn another OASIS file, (for future use) 


c 


V 




Z 




Faerved for pcseihte future uee. 








z 




Thie ia an optional segment* It contains infomation about 
special names. 








3.1 


SPEC.TITLE 


Title other than Mr., Mrs.» Miss, Dr., Ms or blank. When present. It 
is used without exception for all listings and labels. 


c 


8 




4 




This is an optional segment, containing infomatton about special 
names. 








4,1 


PREFERRED, NAME 


Contains name In preferred printing format (24 character maximum). 
It Is used in tho&e cases where MEMBER. NAME contains the format 
required for correct alphabetizing but not preferred for addressing. 


c 


30 




5 




This is an opti^-^al recurring segment, containing informticn about 
prior names* 








5.1 


OTHER. NAME 


Name by which member was formerly known. 


c 


23 






OTH,NAHE 


Redefines OTHER. NAME for indexing. 


c 


12 


Y 


S.2 


OTHER, NAME, TYPE 


Indicates the formatting of this other name. 








5.3 


OTHER, TITLE. CODE 


The correct title associated with this other name. 








5.4 


OTHER. NAME. CODE 


Defines the type of name contained In this se^ent, l.c, maiden, 
former legal , etc. 




V 




5.5 


OTHER, NAME. DATE 


Year and month that this other name was recorded. 








6 




Feeerved for future use» 








7 




Reserved for future use^ 









erJc 
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SSO HO* 
ELEH NO. 


EICMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


a 




Art optional segment eontaining infomation about epeaiat status. 








6.1 


ACT. STATUS. IN 


Codes that Indicate a special n^alllng status of the meniber of the 

Tile. fcAC 1 UUCS fOlUC 0 * 


C 


} 


Y 




ACT. STATUS. UN 


Includes all codes for ACT . STATUS. 


C 


1 




9 




An optional segment containing information about member^s 
relationship to Stanford, 








0 1 


liNIVrQ^tTV QPI 


A coue inuicating vne rreinDer s reiavionsnip to ^tdnToru. 


r 


c 


V 


10 




Beserved for fiiture use , 








n 




Segment containing prinar^i mailing address. 








n,i 


ADDRESS. 1 .LINE 


Line of primary mailing address. Line recurs. 


c 


24 




iz 




fiesejrved for future use. 








23 




Contains ZIP code of first address* 








13.1 


ZIP.1 


lip code of the primary mailing address (P.O. actual for domestic 
addresses* S.U. assigned for foreign addresses). It Is required) 
and Mhen address becoiY^es unknown this zip will be coded '00000* i 
cannot be deleted* 


c 


S 




13,2 


GEOG.ARCA.l 


Geographic code that represents a section or area as defined by the 
University. When zip code Is entered, area Is established by the 
system from the zip table file. 


c 


3 


Y 


14 




Contains telephone area code. 








14.1 


TEL. AREA. CODE. 1 


Telephone area code for this telephone number. 


p 


2 




id 




Contains telephone nunber. 








15. \ 


i TEL. NO. 1 


Telephone number for this address. 


p 


4 




16 




Contains telephone nwnber extension number. 








16.1 


TtL.EXCH.l 

1 

i 


If present* represents the extension at which this person may be 
rcacneu ai lhis auoressi 


p 


3 




I r — 6 V 


I 

! 


Reserved for future use* 








' Bl 




Segment containing first line of second mailing address. 








21.1 


ADDRESS. 2. LINE 


Lines of address for secondary home address. Lines recur. 


c 


24 




22 




Reserved for future use. 




• 




23 




Contains second address ZIP code. 








23.1 


ZIP. 2 


Zip code of the address location and city/state segment. It Is the 
actual US Post Office zips for domestic addresses. 


c 


S 




23.2 


QE0G.AREA.2 


Geographic code that represents the section or area as defined by 
the University. 


c 


3 





ERIC 



OASIS DATA atMENT OlCITlONAftY 



- ALUMNI/GIFT FILE 



tllH NO. 


ri rMPMT 
tLtncni 

NAME 


OESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


24 




Contains telephone area code fcp second address* 








24.1 


TEL, AREA. CODE. 2 


The telephone area code for this phone number. 


P 


2 






* 


Contains telephone numbet^ for second address. 








25,1 


TEL.N0.2 


The telephone number for this address. 


P 


' 1 


26 


■ 


An optional segment which contains telephone extension at telephone 
nurher of second address. 




i 

y 


26.1 


TEL.EXCH.2 


If present, represents the extension at which this person may be 

v*aA^na#4 %^ ^ %/4/4w*ap^ 

reacnea at mi s auuress • 


P 


3 ' 

1 






Reserved for future use, 

. ■ ■ 




1 

t 


33 




■ 

Segment containing first line of third mailing address. 




\ 
\ 

1 


31.1 


ADDRESS. 3. LINE 


Lines of addresses for primary business. Lines recur. 


C 


\ 

24 : 


32 




Reserved for future use. 








^3 




Contains third address ZIP code. 








33.1 


2(P.3 


Zip code of the address location and city/state segments. They 
are the actual US Post Office zips for domestic addresses. 


c 


5 




33.2 


GE0G.AREA,3 


Geographic code that represents the section are area as defined by 
the University. 


c 


3 


Y 


34 




Contains telephone area code for third address - optional. 








34,1 


TFi APFA rnnF i 


icicpnone area couc lor tnis pnonc numDer, 


0 
r 


2 




36 




Contains telephone number of third address - optional. 








3S.1 


TEL. NO. 3 


Telephone number for this address. 


P 


4 








An optional segment which contains telephone extension at telephone 








36.1 


TEl.EXCH,3 


If present, represents the extension at which this person may be 
reached at this address. 


P 


3 




37 




Contains identification of business or corporation shoiM in first 
Zvne of pnJTkiry hustness address. 








37,1 


BUS.] .HEH8ER.ID 


ALUM. ID for the business or corporation shown In the first line 

VI Kilt; priiiKiry oubiness duurcbb. 


c 


7 


Y 


37.2 


BUS.KPOSITION 


Represents the position held by this member for this Business ID. 


c 


10 




37.3 


BUS. 1 .HATCHING 


Indicates the company represented In this segment has a gift 
matchtiig program. 


c 


1 




36^40 




Reserved for fature use. 








41 




Segment containing first line of fourth mailing address. 








41.1 


A0Rt$S,4.LlNE 


lines of addresses for Secondary Business address, lines recur. 


c 


24 





ERIC 



OASIS DATA ELEMENT DICTIONARY 



ALUMNI/GIFT FILE 



SEG NO, 


ELEMENT 

NAMF 

IWlt 


ULdl'n 1 r 1 i\jv\ 


DATA 

TVDr 
1 Tr t 


LENGTH 


lunrvcn 


4B 




Reserved for future uee» 












Containa fourth address ZIP code» 








43.1 


2If>,4 


Zip code of the address location and city/state segments. They are 
tne actuai ud ru>t uiirce zip> lor uoniestic duuresses. 


C 


5 




43.2 


GE00.AREA.4 


Geographic code that represents the section or area as defined by 
the University, 


c 


3 




44 




Contains telephone area code for fourth address* 








44.1 


TEL. AREA. CODE. 4 


Telephone area code for this phone number. 


9 


2 




4S 




Contains telephone nunber for fourth address* 








45.1 


TEL.^0.4 


The telephone number for this address. 


P 


4 




4$ 




Represents the extension at which a person my be reached at 
fourth address. 








46.1 


TEL.EXCH.4 


If presehtt represents the extension at which this person may be 
reached at this address. 


P 


3 




4? 




Identification of secondary business or corporation. 








Al 1 


ovd. c .riLr-OLK. 1 u 


Al lllJ TD ^Av> fha hiiclfiAcc ^mrnnv*<i 1 1 nn chnwn In thft fivct lino f\f 

nLun.iu lur tile uusif}c>s ur curpuratiun aiiunii in tnv fir>t iiiic ui 

the secondary business sddress* 




in 


Y 


47.2 


BUS. 2. POSITION 


The position held by this member for this Business ID. 


C 


10 




^/ . J 


OUa.c.rinlLninu 


1 Mc conipany rcprcacriLcu in iiiia scgnicnL na> a ^ 1 1 1'lnaLLn i pru^r^ii'ii 




1 

1 








Reserved fot* future use. 








it 




Segmnt representing a ZIP code area in which an alumni club operates. 








Sl.l 


ALUMNI .CLU8 


A code that represents a zip area In which an alumnf club operates. 


c 


2 


Y 






Reserved for future use. 








55 




Contains ID of echool or department associated with a particular 
mailing* 








SS.1 


ORG. ID 


A code used to Identify the school or department associated with this 
organization mailing. 


c 


1 






Apr 1 1 e T T n 


n COQc vU i<ieiii*fjr iTfTiCfi nrai'in^ flat in i.ni> vr (jani^a t lun tffi> Ricifiucr 

is Identified with. 


c 


1 






ORG. 10. AND. LIST 


Redefines 55. 1 and SS.2 for Indexing. 


c 


2 


Y 


5S.3 


ORG. MULTI. COPY 


The number of copies this member desires of a speclffc mailing. 


c 


2 




55.4 


ORG.ADO.PREF.HM 


Code specifying the address to which this mailing Is to be sent, 
if not to 'norniar {1st) business address. 


c 


1 




55 




Indicates exception to a usual 'home* address mailing. 








56. 1 


ADD. PREF. HOME 


Indicates an exception to a usual 'home' address mailing (I.e., when 
primary home address Is not to be used In requests for 'home address* 
mall Ings). 


c 


1 





erJc 



OASIS DATA ELEMENT DICTIONARY - ALUHNI/6IFT FILE 



SEO SO, 
ElEH NO. 


ELEMENT 
fiAHE 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


$6.2 


AOD.PREF.aUS 


Indicates an exception to a usual 'business^ address mailing 
(I.e. r when primary business address 1s not to be used In 


C 


1 




56,3 


ADD.PREF.OBSVR 


The address to which the Observer/Almanac Is to be sent. 


C 


1 




56.4 
56.5 
56.6 


A0D.PREF.BULK.2 
A0D.PREF.BUU.3 
AD0.PREF.BUIK«4 


Addresses to which future bulk mailings may be sent. (Expansion) > 

J 


c 


1 




$7*69 




Reserved for* future u$0^ 








60 




Optional Begment containing ID, TYPE if merriber on other OASTS file* 








60.1 


OTH. MEMBER. 10 


Ths 10 number of member who has a different 10 number tn another 
OASIS file. 


c 


10 




60.2 


OTH. MEMBER. TYPE 


Other file In which this person resides under another 10 number. 


c 


1 




SI 




optional segment containing ID, TYPE if spouse is on other OASIS files. 








61.1 


FAM.REL.ALUM.ID 


Member 10 of the current spouse of this member, who Is a member 
of the OASIS files. 


c 


7 


Y 


51.2 


FAM. RELATION 


Relation code for this member ID. 


c 


1 




61.3 


FAM. RECORD. TYPE 

■ 


The other OASIS file of which this Spouse is a member. 


c 


1 








Reserved for future use. 








70 




Optional segment containing basic Alumni Assoc* and degree data. 








70.1 


BAS. ALUM. ASSOC. I^ 
BAS. ALUM. ASSOC. UN 


Code which defines this member's status with the Alumni Association. 
Excludes Value '0' . 

Same as 70.1 - Includes all Values. 


c 


1 

1 


y 


70.2 


BAS.SOC.CL.YEAR 


The year to be considered this member's social class year. This 
Is normally the year In which an undergraduate would graduate 
or has graduated. 




2 




70.3 


BAS.0E6.UG 


Member* s undergraduate academic achlevetnent at the University. 




1 




70.4 


8AS.DEG.6RAD 


The status of member's graduate achievement at the University. 


c 


1 






8AS.DEG. STATUS 


Redefines 70.3 and 70.4 for Indexing. 




2 


Y 


71 




An optional ^^curring segmett sumarizing achievement to be used 
for alumi i^cords* 








71.1 


ACQ. LEVEL 


Represents the levsl of achievement. 






1 




71.2 


ACQ. SCHOOL 


The school In which this member did his acadanic work In the 
major Indicated. 






1 




71.3 


ACAD.MAJOJ^ 


The acade.^ic major of this member. 


c 


1 






ACQ. SCHL. MAJOR 


Redefines 71.2 and 71.3 for Indexing. 




3 


Y 


71.4 


ACD.YEAR 


The year in which this level of achievement was completed. 




4 




71.5 


ACD.DEG.OTRS 


Number of quarters completed or the degree conferred on this 
member. 




3 




7Z 




'.ptional recurring segrnent, contains indicators as defined hy the 
organisation. 









OASIS DATA ELEMENT DICTIONARY - ALUMNI/GIfT FILE 



ELEM NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


72.1 


STANFORD. ORG. lU 


A code which Identifies the organization (school/dept.) for 
which this Information Is being maintained. 


C 


1 


Y 


72.2 
THRU 
72.10 


STANF0R0.ORG. 1 

THRU 
STANFORD. ORG. 9 


Flags which contain codes specific to the organization represented 
In the ID. 


C 


• 

1 








Optional reourring segment^ oontaine type and length of service* 








73.1 


ST ANF . SRY .ORG . 1 U 


A code that Identifies the organization (school/dept.) associated 
with this service. 




1 


V 

T 


73,2 


STANF.SRV.CODE 


A code that Indicates kind of service to this organization 
(school/dept.). 


C 


1 




73.3 


STANF.SRV.FREQ 


NufTiber of years of service of this member to this organization. 


C 


1 




73.4 


STANF.SRV.LAST,yR 


The year this member last served In this capacity. 


P 


3 




74 




An optional reourring segment containing one occurrence for each 
residence where student lived. 








74.1 


RESIDENCE. CODE 


On-campus or overseas campus residence for this member. 


c 


3 




74,2 


QYY.RESIDeO 


field containing the quarter and year (last two positions) this 
member resided at this residence. 


p 


2 




76 




Optional reourring segment^ contains code identifying student act. 








75.1 


STUDENT. ACTIVITIES 


Records volunteer and extra currlcular activities while member 
was a student. 


c 


4 




76 




optional segment , contains code identifying current occupation. 








76,1 


OCCUPATION 


Records the member's occupation. 


c 


4 




77^99 




Fesei'vcd for future use. 








100 




This eegtnent indicates the anount of gifts that file rnember has 
given in current year, last year, and in total to the University, 








100.1 


DNR. STAT. TOTAL 


The range In which total gifts to the University from this member 
would fall . 


c 


1 




100.2 


DNR.STAT.CURR.YR 


Range In which current year's gifts from this member would fall. 


c 


1 




100.3 


DNR. STAT. LAST. YR 


The range In which last year's gifts from this member would fall. 


c 


1 






DNR. STAT. TCL. IN 


Redefines 100.1, 100.2, and 100.3 for Indexing. Excludes Value 
•OOA'. 


c 


3 


Y 




DNR. STAT. TCL. UN 


Redefines 100. U 100.2, and 100.3 to Include all values. 


c 


3 




100.4 


DNR. STAT. FREQ 


Number of fiscal years In which this member was a donor. 


c 


1 




102 




This segrrjent identifies certain annurd solicitation methods 
through which file member is aolicUed for gifts to the University, 








101,1 


AF. PROGRAM. ID 


Code to Identify the Annual fund Programs to which this member 
belongs. 


c 


1 


Y 


101.2 


AF. PROGRAM. STAT 


Special status of the member of this Annual Fund program. 


c 


1 




101.3 


AF.PROG.ADDR 


Address code to Indicate Campaign Region selection. 


c 


1 




101.4 


AF.DATE 


Date indicating date added to program. 


c 


4 




0 













ERIC 



Oasis data element dictionary - alumni/gift file 



SEG NO. 
ELEM NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


m 




Thie segrneni identifiee epeaial memberehip in eotioitation program. 








102.1 


SPEC.ALUH.PAOG 


Codes that Indicate this member's special ALUM. PROG membership. 


C 


1 


Y 


102.2 


SPEC. ALUM. STAT 


Code Indicating the current status In the SPEC. ALUM. PROG . 


C 


1 


Y 


102,3 


SPEC. ALUM. BEQ 


A flag that, when seti Indicates this member fs a prospect for a 
bequest. 


C 


1 




20S 




Thie segment indentifies the various schools from which a menjber may 
receive solicitation. 








103.1 


FUND. 10 


A code which indicates the fund for which this segment exists. 


C 


1 




103.2 


FUND.YR 


Social class year of this member's school affiliation. 


C 


2 






FUND. ID. YR 


Redefines 103.1 and 103.2 for Indexing. 


C 


3 


Y 


103.3 


FUND. PROS. TYPE 


Optional Information defining prospect groups within the fund. 


C 


1 




103.4 


FUND. CUR. RATING 


Code representing the range in which current yearns gifts to this 
fund from this member would fall. 


C 


1 






rUnU.LAdl . Kn 1 i Hu 


Code representing the range fn which g^f^s by this member In last 
year prior to the current year would fall. 


L 


1 
1 




103.6 


FUND. TTL .RATING 


Code representing the range In which total gifts by this member 
to this fund would fall« 


c 


1 




103.7 


FUND. PREF. FLAG 


The preferred fund for member at this time. 


c 


1 




103.8 


FUND. SPEC. HAND 


Flag whtchi when seti Indicates this fund member should not be 
solicited for this fund at this time. 


c 


1 




104 




This segment identifies a donor's interest in the University pertinent 
to fund raising* 








104.1 


OONOR. INTEREST 


Code showing Interest of the member as a prospect. 


c 


2 


Y 


104.2 


OONOR. PURPOSE 


Purpose of Interest as shown by gift purpose. 


c 


2 






OONOR. INT. PURP 


Redefines the Interest of this member. 


c 


4 




104.3 


DONOit. GIFT. FLAG 


Flag which, when set. Indicates this member has been a donor to 
this Interest. 


c 


1 




m 




Reserved for future use. 








106 




This eegrvent indicates special volunteer service to the University, 








106.1 


FUND. SVC. CODE 


Fund-raising organization service group with which {this member Is 
associated. ^ ; 


c 


2 


Y 


106.2 


FUND. SVC. EFFORT 


Special effort within the fund service group with whl^h this person 
Is associated. 


c 


1 




106.3 


FUND. SVC. YR 


The year member was enlisted in this service. 


p 


3 




10? 




This segment records the status of a member of gift carnpaign 
prospect group. 








107.1 


PROSP.CHP.ID 


This Is a code which represents the campaign ID in which this person 
Is a prospect. 


c 


2 




107.2 


PROSP.AREA.STRUC 


Area-region, team number, and volunteer number to which member 
Is assigned. 


c 


10 





OASIS DATA ELEMENT DICTIONARY - ALUMNI/GIFT FILE 



$SG NO. 
ELEH ND. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(8YTES) 


INDEXED 




PROSP.IO.AREA 


Redefines 107.1 and 107.2 for Indexing. 


C 


5 


Y 


107.3 


PROSP. REPORT .CDE 


Results of a volunteer call upon this campaign prospect meniber. 


C 


1 


Y 


107.4 


PROSP .MARR. CODE 


Flag whichi when seti Indicates that this can^pa 1 gn prospect has 
a spouse on the OASIS file who Is considered with the prospect 

S^K !k c<imn<i Ian Hnnnr a nH nrn^npr t 


c 


1 




107 5 


PRHP^ AFT Amount 




p 


7 




107.6 


PROPS UPO PI FOf^F 




p 






20$ 




This segment identifier volunteer actiiHty vithin a gift oarnpaign. 








108.1 


VOL. CMP. ID 


Ca^npalgn prospect ID (and gift source) this volunteer Is assigned to. 


c 


2 




108.2 


VOL AREA, STRUCT 


Area^realon. team nuniber. And volunteer number asslaned volunteer. 




10 






VOL ID.ARFA 


Redefines 108.1 and 10A 2 fnr Indexina 


c 


5 


Y 


108.3 


VOL. LEVEL 


Title and level of responsibility at which this volunteer 1s 
working In this campaign. 


c 


1 




iUtf 




irIl'O «&yfTt;TiC rvvvrCLa trie flVVtOn^OCLw dCtfrU WC^l'WH'^tJj^ ai^Vvwvffjf U 








10^.1 


VOL. HIST. CMP. ID 


Same codes as those used for campaign volunteer. 


c 


2 




109.2 


VOL. HIST. LEVEL 


Title and level of responsibility at which this volunteer is working 
In this campaign. 


c 


1 




109.3 


VOL. HIST. FREQ 


The number of years this volunteer has worked in this program at this 
1 eve) . 


c 


1 






vni H T S T nATF 


LflaL Ud LC UI aCfV 1 Lc lUF YUlUllkCCr ■ ■■ kills ^lUyTOlll d V kills ICVCI. 


p 


•J 




mo 




uuuc UaCU vj Lanipai^n aiiu pruyrani sLaii triaiiaijcr^ ra^c viic 

effectiveness of a volunteer. 




) 




I sv 




pertinent to fxmd t^ieing. 








110.1 


PROJ.FOL.UP. ID 


Type of institution to which this proposal was made. 


c 


1 




110.2 


PROJ.FOL.UP.RATG 


Evaluation of this Institution according to capitalization, 


c 


2 




110.3 


PROJ.FOL.UP. INT 


The 'Interest* for which this proposal has been made. 


c 


3 




iin d 

1 1 u . t 


PftOJ FOL UP STAT 


Codp coAtainlna thp (t^tufi of this oroDOSal . 


c 


1 




110.5 


PROJ.f^OL.UP.OATE 


The date this proposal wai submitted. 


c 


4 




110.6 


PROJ.FOL.UP.MEMB 


Flag indicating If this institution is a part of an Annual Fund 

^1 U>J f QIm • 


c 


1 




lit 




This segment indicates this member should receive no University 








111.1 


DO. NOT. SOLICIT 


Flag which, when set, indicates the person should not be sollcltated. 


c 


1 


Y 


112 




This segment indicates the busineee affiliations of a nerfiber* 








112.1 


BUS. AFF. NAME 


Name of a business with which this member Is associated. 


c 


23 




112.2 


BUS.AFF.MBR.ID 


Member 10 of this business. 


c 


10 






BUS. AFF. ALUM. 10 


Redefines meinber ID for Indexing. 


c 


7 


Y 



OASIS DATA ELEMENT DICTIONARY - ALUMNI/GIFT FILE 



$E0 HO, 
ELEH NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


112.3 


BUS.AFF.POS 


The position member holds In this cocnpany. 




C 


10 




112.4 


BUS.AFF. MATCH 


Flag Mhlch, when set. Indicates that this business has a gift- 
matching program. 


C 


'l 




m 




Feeerxfed for future use. 










114 




This segment reoords the narrie of the mmher* 


6 non-alvmus spouse. 








114.1 


OFF. SPOUSE. NAME 


Name of this rubber's current spouse v^ho Is not a member of an 
OASIS file. 


C 


23 




114.2 


OFF. SPOUSE. CODE 


Code that Indicates that this spouse Is the 
member. 


current spouse of this 


c 


1 




US 




This eegtnent cross references the r\erber*s alurmi or current 
student children. 








115.1 


CHILO. MEMBER. ]D 


MEMBER . ID of a chHd of tMs member Mho Is also a member of 
an OASIS file. 


c 


10 






CHILD. ALUM, ID 


Redefines 115.1 for Indexing. 




c 


7 


y 


115.2 


CHILD. CODE 


Code which Identiftes this child, 




c 


1 




216 




This segment records the names of a member 
rvOK-ali47mC. 


children who are 








116.1 


OFF. CHILD. NAME 


Name of a child who Is not a member of an OASIS file. 


c 


23 




1T6.2 


Of F. CHILD. TfTL£ 


Title associated with this off-file child. 




c 


8 




116.3 


OFF. CHILD. CODE 


Code which Identifies this child. 




c 


1 




11? 




This segment cross reference alurmi relatives of the member. 








117.1 


REL . MEMBER . 1 D 


MEMBER. ID of a relative or special related person who Is also a 
member of the OASIS file. 


c 


10 






REL.ALUK.ID 


Redefines 117.1 for Indexing. 




c 


7 


Y 


117.2 


REL.DESC 


A description of this relationship. 




c 


10 




118 




This segment records names of non-alumi relatives of a member. 








118.! 


OFF. REL. NAME 


Name of a relative who is not a member of an OASIS file. 


c 


23 




118.2 


OFF. REL. TITLE 


Title of this off-file relative. 


\ 




c 


8 




118.3 


DFF, REL .DESC 


Description of the relationship to this meml 






c 


to 




119 




This segment cross references associates of 


this member vho are at 


imi, 








119.1 


ASSOC. MEMBER. ID 


- 

MEMBER. ID of an associate who is also a member of an OASIS file. 




c 


10 






ASSOC. ALUM. ID 


Redefines 119.1 for Indexing. 


\ 


c 


7 


Y 


119.2 


ASSOC. DESC 


A description of the association. 




c 


ID 




no 




This segment records names of non^atumi associates for a merrier. 








120.1 


OFF .ASSOC.NAME 


The rtame of an assolcate who Is not a member of an OASIS file. 


c 


23 




120.2 


OFF .ASSOC.TITLE 


The title of this associate. 




c 


8 





ERIC 



OASIS OATA ELEMENT DICTIONARY - ALUMNI/GIFT FILE 



SEG NO. 
illH NO. 


ELEMENT 

NAME 


OESCRIPriON 


OATA 
TYPE 


LENGTH 

{eyiEs) 


INDEXED 


120.3 


OFF. ASSOC. OESC 


A {description of thts association. 


C 


10 




lei 




Thie eegment reaox^e a pledge of money to be given to the UniverB'Cty 
by a member* 








12M 


PL£06E. SOURCE 


Campaign or project effort that generated this pledge. 


C 


2 




121.2 


PLEOGE.OATE 


The date In format YYMDD that this pledge was recorded with Stanford. 


c 


6 




1 £l . J 


r L L Ub t . AnUUN 1 


Unpaid Da lance of this pledge. 


p 


7 






KLUu . ACt 1 » NO 


Fund account number to which this pledge Is to be credited. 


c 


16 




1 01 C 


DI CATC ilMUDrO 

rL tube * NUno LK 


Number which foentlftes this pledge. 


c 


5 


Y 


121.6 


PLEOGE.IST.PAYOV 


A date (YYMDD) that the pledge payment Is due from this member. 


c 


4 




121.7 


PLEOGE.FREQ 


Frequency of reminders to be sent this merber for his pledge 
payment. 


c 


1 




121.8 


PLEDGE. PAYMT.AMT 


Amount of each pledge paymenc. 


p 


7 




121.9 


PLEDGE. SPEC.HAND 


Code which specifies the handling of pledge reminders. 


c 


1 




121.10 


PLEDGE. A. MATIC 


Flag which Indicates that this pledge Is on an automatfc bank 
withdrawal system. 


c 


1 




122 




Thie segment eurmarizes gifts priop to 19 BO for this memhep* 








1 90 ) 

Ic?. 1 


u I r 1 . ^uri. VOL 


Number of gifts represented by this suiwiary. 


6 


C 




1ZZ.2 


GI FT . SUM . OATl 


Date of the last gift In this sunmary in the format YYMDD. 


C 


6 




Ire. 3 


GI FT .SUM. AHT 


The sum of all gifts summarized In this record. 


P 


7 








This eeg--ent reGords each gift received from a member since 1960, 








123.1 


GIFT. SOURCE 


Campaign •>r effort that generated gift. 


c 


2 




123.2 


GIFT. DATE 


Date that gift was received by Stanford. 


c 


6 






GIFT. SOURCE. YY 


Defines source and year for Indexing. 


c 


4 


Y 


123.3 


GIFT. AMOUNT 


Amount of the gift. 


p 


7 




123.4 


6IFT.ACCT.no 


Indicates to which fund account this gift is credited. 


c 


16 






b 1 r 1 . 1 Ab • nu 


The serial number of the gift acknowledgement. 


t 






1 cJ.o 


riCT AtJHM 
u 1 r 1 . nnUn 


Flag indicating that this gift should be kept externally anonymous. 


f 


1 




1 91 7 


Girl. u 1 1 tnBt K 


Flag to indicate that this Is a December gift received in January. 


i» 


1 




1 91 Q 


Glrl.lTrt 


Type of gift that has been posted to member's record. 


/> 
t 


l 
1 


T 


1 91 Q 


Glr 1 .oT.UIHLK 


A flag which* if present* indicates gift was received from a donor 
other than member. 


c 


\ 






t 


Optional recurring segment^ contains transactions cf pledge (seg IBl), 








124.1 


PLDG. TRANS. NO. PY 


Number assigned to this pledge in the file. 


C 


5 




124.2 


PLDG. TRANS. AHT 


Amount paid on this pledge number. 


P 


7 




124.3 


PLDG. TRANS. DATE 


Date of this paytnent on the pledge was made. 


P 


4 




124.4 


plog.trans.no 


Number of cash transactions ticket. 


c 


5 





OASIS DATA ELEMENT DICTIONARY - ALUMNI/GIFT FILE 



SEG nO» 
ELEH NO. 


tLtntm 
NAME 


DESCRIPTION 


UATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


IBS 




Optional recurring segment; Burmry of gifta for each fund per member 








12S.1 


FD.GFT.ID 


Identffie^ whfch fund Income fs sumnarlzed. 


C 


■l 




125.2 


FD.GFT.CURR.YR 


Summary of fund income for current year. 


P 






125.3 


FD.6FT.LAST.YR 


Surmiary of fund Income for last year. 


P 






125.4 


FD.GFT.YR.LESS.2 


Summary of fund fncome two years ago. 


P 






125.5 


FD.GFT.YR.LESS.3 


Surmary of fund income three years ago. 


P 






125.6 


FD.GFT.TOT 


Surfinary of fund income in total. 


P 






226 




Optional segment; eumary of gifts for thie member. 








126.1 


TOT.GFT.CURR.YR 


Total gifts to the University by this member in current year. 


P 


r 




1 26.2 


TOT . 6FT . LAST. YR 


Last year's gifts ln total by this member to the University. 


P 






126.3 


T0T.GFT.YR.LESS.2 


Total gifts to the University by this member two years ago. 


P 






126.4 


T0T.GFT.YR.LESS.3 


Total gifts to the University by this member three years ago. 


P 






126.5 


TOT.GFT.TOT 


Total gifts to the University by this member* 


P 


7 




127-34 




Reserved for future use. 








US 




Optional recurring segment; additional infomxtion for thie mender. 








135.1 


SIV. COMMENTS 


A free-form non-coded field In which information may be added 
to a member' s record. 


C 


30 





i 

i 



OASIS DATA ELEMENT DICTlONARy • EMPLOYEE FILE 



SSQ NO, 
ElEH NO. 


ELEMENT 
rwnt 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


1 




Segment 1 oontcining baeia identification data^ oooure once per 
employee. 








1.1 


MEH8ER.ID 


Social security nuinber> preceded by a Z. 




C 


10 


Y 


1.2 


HEH8ER.NAHE 


Name of employee forfaited: Last, First, 


Middle. 


C 


23 






MEM. NAME 


First 12 digits of VEMBER.NAME. Pedeflnes MEMBER. NAME. 


c 


12 


Y 


1 1 
1 • s 




Employee's sex. 




r 
K, 


1 


V 

T 


1.4 


MAP.ITAL. STATUS 


Marital status of eflip'oyee. 




c 


1 




1.5 


81RTK,DATE 


Strth date of employee, 




z 


6 


Y 


1.6 


LAST. TRANS. DATE 


Day of the update on which a change was made to employee's record. 


p 


4 








Reeewcd for future use. 










S 




This ie an optional recurring segment, containing inforrkition about 
prior fuvnee. 








5.1 


OTHER. NAME 


Name by which employee was formerly known. 


c 


23 




5.2 


OTHER. NAME. CODE 


Type of name contained In segment. 




c 


1 




5.3 


OTHER. NAME. DATE 


Year and month that other name was recorded. 


c 


4 




6 




Reserved for future u5e. 










7 




An optional eegment relative to emergency contact. 








7.1 


cncRG . NAME 


Name of the person that should be contacted In emergency for employee. 


c 


Z3 








Reserved for future use. 










U 




A recurring segment containing home address. 








11.1 


HOME. ADDRESS 


1st occurrence: street address. 
2nd occurrence: city and state. 




c 


24 




n 




Reserved for future use» 










n 




Contains ZIP code of home address. 










U.l 


ZIP.l 

i 


ZIP code of home address. Cannot be dele 
unknown. 


;ed; zeros If ZIP code is 


c 


5 


Y 


M 




Resey^ed for future use» 










15 




Contains telephone number at home address. 








15.1 


TEL. NO. 1 


Telephone number at home address. * 




p 


4 








Reserved for future use. 










41 




Recurring seg^nent containing emergency contact address. 








4M 


EMERG. ADDRESS 


1st occurrence: street address 
2nd occurrence: city and state 




c 


24 





OASIS DATA ELEMENT DICTIONARY • EMPLOYEE FILE 



SEG W, 
ELEH NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


42 




Fe&ewed for future uae. 












Contains emergency addrees ZIP code. 








43.1 


ZIP. 4 


Emergency ad<iress ZIP code. 


C 


5 




44 




Reserved for future uee. 








4S 




Containe telephone number at emergency addreea. 








45.1 


TEL.N0.4 


Telephone number at emergency address. 


P 


4 




4$' S3 




Reserved for future use* 








64 




An optional segment containing address aimiliarity indicator. 








64.1 


ADD. SIM. FLAG. 1 


Indicates that hofne and emergency address are the same. 


C 


1 




SS-S9 




Reserved for future uee* - 








€0 




Optional recurring segment containing identification number of 
employee in another five* 








60.1 


OTH. MEMBER. ID 


The ID number of an employee in another file for Inte^-flle reference. 


C 


10 




60.2 


OTH. MEMBER. TYPE 


Other file to whfih this person resides under another 10 nu i)er. 


C 


1 




62 




Optional segment containing family relationship infomation. 








6M 


FAM.REL.MEM.II1 


identification number of family rrember who is in this or another 
OASIS file. 


C 


10 




61.2 


FAM. RELATION 


Relatiofk code for family member. 


c 


1 




61.3 


FAH. RECORD. TYPE 


OASIS file in which the family member resides. 


c 


1 








Reserved for future use. 








71 




An optional segment sumarising academic achievement at Stanford* 








71.1 


ACO. LEVEL 


Level of academic achievement at Stanford. 


c 


1 




71.2 


ACQ. SCHOOL 


School in which employee was enrolled for work In major indicated. 


c 


1 




71 .3 


ACD , MAJOR 


Major field of study at Stanford, 


c 


^ 

c 




71.4 


ACO.YEAR 


The year fn which this level of achfevement was completed. 


c 


4 




71.5 


ACD.DEG.QTRS 


Number of quarters or degree conferred on employee by Stanford. 


c 


3 




71.6 


ACD.ACH.QTR 


School quarter In which the academic level was achieved. 


c 


1 








Reserved for future use. 








291 




A required segment containing basic employment dates and employee 
status indicators. 








191.1 


PAYROLL, GROUP 


Regular or casual employee status or type of employee relationship 
to Stanford. 


c 


1 


Y 



OASIS DATA ELEMENT DICTIONARY - EMPLOYEE FILE 



SEO NO. 
ELEM NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


191.2 


PR.SUPPL.CODE 


Designates that employee was paid this payroll on a supplemented 
payrol 1 . 




V 




191.3 


EMPL. START. DATE 


Date that employee relationship started with Stanford. 


p 


\ 


Y 


191.4 


EMPL. START. CODE 


Type of hiring status of employee. 


c 


2 


Y 


191.5 


EMPL. ADJ. ST. DATE 


tfTployment start date as adjusted by leaves or previous employment 
status. 


p 


4 




191 .6 


FMPL END DATE 


hxto nf tpnnlh'^Mnn froin ^f^infnrH nr 1p;)\/p ctxtuc <fArt H^fo 
ua ui iCiHiiiiokiuii iiuiii ji>aii«uiu \it leave status dtait uolc| 

depending on EMP. END, CODE . 






Y 


191,7 


EMPL. END. CODE 


Reason for employee separation frooi Stanford or leave status type. 


J. 




Y 


191.8 


EXP, WORK. END. DT 


Date of expected end of appointment or authorized work period. 


p 


4 




191.9 


APPL. STATUS 


Designates availability for Job openings. 


c 


2 


Y 


191,10 


APPL. SOURCE 


Physical source of application (e.g., mall). 


c 






m 




An optional segment that containe Job ctaBsification data, minority 
etatu3j leave, and employee group mmberehip indicatore. 








192.1 


J08. CLASS. CODE. 1 


First of two possible Job classification codes. 






Y 


192.2 


PER. CENT, PTE. 1 


Percentage of time worked In 008. CLASS. CODE . 1 . 






Y 


193.3 


JOB. CLASS. CODE. 2 


Second of two possible job classification codes. 






Y 


192.4 


PER. CENT. PTE. 2 


Percentage of time worked In JOB .CLASS .CODE .2 . 


p 


2 


Y 


192. S 


F.S.CODE 


Type of work grouping for selection In various mailings, and in 
phone directory Inclusions. 


c 


, 




192.6 


PROF. EXP. ST. YR 


Starting year of professional experience Is inserted In this field. 




2 




192.7 


PATENT. AGR. CODE 


This code Indicates whether or not the employee has signed a patent 
agreement and Indicates any exclusions. 








192.8 


TENURE. STATUS 


Tenure status of faculty members. 


c 






192.9 


EEC. CODE 


Minority status code as defined by the EEOC, 


c 




Y 


192.10 


EEO.SUPPL.CODE 


Added definition within EEO.CODE as required in Stanford 
Affirmative Action programs. 


c 






192. 11 


ALUM STATUS 


Tndlfdtes whether or not emolovee hds ever attended Stanford as a 
Student. 








192.12 


LV. MO. TOTAL 


Total number of months of leave from Stanford since EMPL , START .DATE 








192.13 


LAST. ACT. TYPE 


Last type of action against basic employee data. 






Y 




LAST. EPF. DATE 


Date of last action against basic employee data. 






Y 


192. IS 


AWARD. AMT 


Employment-to-date amount of financial awards. 












Optional segment containing federal and eUxte tax status codee. 








193.1 


FED. WH. MARITAL 


Marital status for federal tax withholding purposes. 


I 






193.2 


FED. UH. CODE 


Number of taxable exemptions or special tax codes. 








193.3 


FED. WH. YEAR 


Year in which the federal withholding declaration was made. 








193.4 


FED. WK. ADD. EX 


Number of additional federal withholding amounts as specially 
requested by employee. 








193.5 


STATE. WH, CODE 


Shows whether or not the employee is taxable In California. 









o ■ 

ERLC 



OASIS DATA ELEMENT DICTIONARY • EMPLOYEE FILE 



$E0 NO. 
ELEM NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


193.6 


STATE. WH. MARITAL 


Marital status of employee for California tax purposes. 




2 




193.7 


STATE. WH. EXEMPT 


Number of exemptions claimed for California tax purposes. 


p 


2 




193.8 


SOC. SEC. STATUS 


Social Security tax status. 


c 


2 


Y 


m 




Ai optional segment containing insuranae program enrottmnt indioators 
and eligibility faotora. 








194.1 


RETIREMENT. CODE 


Type of retirement plan participation. 




1 


Y 


194.2 


LIFE. INS. CO:)E 


Level of group life Insurance coverage. 




1 


Y 


194.3 


ACCID. INS. CODE 


Number of family members Insured under the accidental death and 
dismemberment policy. 




1 


Y 


194.4 


UNEMPL.OIS.CODE 


Basic eligibility for unemployment compensation and disability 
Insurances. 




1 


Y 


194.5 


HEALTH. INS. CODE 


Medical plan enrollment and v/hether dependents are covered or not. 




1 


Y 


194.6 


MAJ. MED. CODE 


Enrollment In major medical plan. 




1 


Y 


194.7 


GIFT. INDICATOR 


Participation in payroll deduction programs for charities and gifts. 




1 




194. d 


PRESS. DIS. CODE 


Enrollment In special disability program for members of press work 
group. 




1 




1C4.9 


AUTO. INS. CODE 


Enrollment In automobile Insurance program. 




1 




194.10 


CREO. UNION. CODE 


Type of employee Interaction with Stanford Credit Union. 


c 


1 




194.11 


CAMPUS. FAC.CODE 


Employee participation In Stanford recreation association and 
faculty club. 




1 




194.1? 


CAMPUS. LIV. CODE 


Shows commitments related to living on Stanford lands. 


c 


1 




194.13 


SU.ItiDE6T.C0DE 


Indicates whether or not employee has a loan outstanding from 
Stanford. 




1 




194.14 


TAX. SHELTER. CODE 


Enrollment In any tax shelter plan other than under the Prudential 
or TIAA-CREF retirement plans. 




1 




194,15 


SPEC. PAY. CODE 


fn'llcates whether or not employee has had a special one-time payment. 


c 


1 




194.16 


ROOM. 80ARD. CODE 


Code indicating whether or not the employee is paying board and/or 
room charges to Stanford. 




1 




194.17 


TIAA.LIFE.MISC 


Shows participation In special TIAA life Insurance program^ or If 
had miscellaneous payment to Stanford. 




1 




194.18 


UNION. DEO. CODE 


This field will show If deductions are made to pay for union dues. 


c 


1 




194.19 


OTHER. DEO. CODE 


Indicates whether or not deductions are made which are not 
categorized In this segment. 




1 




194.20 


LTD. INDICATOR 


Specific eligibility for Stanford's long term disability program 
and California unemployment and disability Insurance plans. 




1 


Y 


194.21 


WORK. COMP. CODE 


Eligibility code for Workmen's Compensation program, ^ 




2 


Y 


194.22 


DEPENDENT. TOTAL 


Number of actual dependents related to employee. 


p 




Y 


m 




optional eegpn^nt whiah contains codes designating StccnfoTfid student 's 
terminal graduate status, and undergraduate class year ot* graduate 
major field* Also shoos eligibility for tuition^grant program 
benefits. ' ' ' 








195.1 


TERM. GRAD. CODE 


Ind1cate$ whether or not employee Is classified as a terminal graduate 
at Stanford. 


c 


. 1 





OASIS DATA ELEHENT DICTIONARY - EMPLOVEE fILE 



$E0 m. 

ELEM NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


195.2 


entl.tu.gr 


Shows If employee Is entitled to tultlon-grait program benefits. 


C 


1 




1 nc ^ 


CLASS . HA JOR . CODE 


Class year ff employee Is an undergraduate Stanford studenti or 
the major field designation If employee Is a Stanford graduate 
student. 


C 


"3 




m 




An optional eegrnent uhioh holds hank identification and employee 
account number for direct eatary deposits. 








196.1 


BANK. DEP. BRANCH 


Branch Identification number of employee's bank where the net 
salary ts to be deposited automatically. 


P 


4 




196.2 


BANK. DEP. ACCT 


Employee's bank account number ts reconied in this field. 


P 


6 




196.3 


SANK. DEP . A8A 


The ABA number of the employee's bank Is Inserted In this field 
for automatic deposit plan purposes. 


P 


3 




19? 




Optional recurring segment used onttf when Social Security Nwnber 
requires correction. Contains date of change, old or Keii> nienber 
and code indicating which. 








19M 


SSN.CH.TYPE 


Code Indicating whether the Social Security Numbiir In the 
SSN.CH.NO Is the obsolete one or the new number. 


c 


1 




197.2 


SSN.CH-NO 


Obsolete or new Social Secuiity Number for the employee 
depending upon SSN . CH - 7 l*'E . 


p 


5 




197.3 


SSN.CH . DATE 


Date of Social Security NiTher change. 


p 


4 




m 




Optional recurring segment holding detailed salary or wage data 
needed for paying employee. One segnent is generated for each 
account number used. 








198.1 


PP. CODE 


Indicates type of permanent Pay Mm, 


c 


2 


Y 


198.2 


PP. START. DATE 


Date that pay recorded In this segment Is scheduled to start. 


p 


4 




198.3 


PP. STOP. DATE 


Date that the pay In this segment Is scheduled to stop. 


p 


4 




198.4 


PP. ACCT . NO 


Account number being charged for the pay Item. 


c 


7 


y 


198. S 


PP. ACCT. GL. CODE 


Expenses classification code relating to the work performed. It 
should re noted that the last three positions of this code are 
the firs' three positions of the Job classification code. 


c 


S 




198.6 


PP.f IN. RPT.CODE 


financial reporting category corresponding to the expense 
classification code In use. - 


c 


s 




198.7 


PP.Ar- .V/P.CODE 


Type of aCjtlon resulting In the creation of the Permane^'it Pay item. 


c 


1 




198.8 


PP. PERCENT 


Percentage of full time equivalency assigned to the Permanent Pay 
Hem. 1 


p 


2 




198.9 


PP. STATUS 


Status of the Permanent Pay Itii^i, such as "DO" for salary Distribution 
Offset. I 


c 


2 




198.10 


PP. AMT . ft/ TE 


lha salary amount or hourly rate. 


p 


4 




m 




1 

An optional recurring segment containing detailed deduction inforryztion 
for insuisxyioe plims and other programs. One segment is gen^^rated for 
each type of deduct* on » 








199.1 


DED.COOE 


Specifies th^ deduction reason or Insurance program. 


c 


2 


Y 


199.2 


OED. START. DATE 


Start date for the de<^uct1on Item. 


p 


4 




199.3 


DED. STOP. DATE 


Contains che stop date related to the deduction item. 


p 


4 





OASIS DATA ELEMENT DICTIONARY - EMPLOYEE F!L£ 



ELEH NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


199.4 


OED. STATUS. CODE 


Information relating to the amount contributed by Stanford towards 
payment for benefit programs. 


C 


2 




199.5 


DED. AMOUNT 


The amount of the deduction to be taken. 


P 


4 




ZOO 




Optional segment holding vacation and sick leave balances determined 
annually n 








200.1 


VAC. BAl. DATE 


Date of the last balancing of vacation accrued less vacation taken. 


P 


4 




200.2 


VAC. BALANCE 


Contains balance of vacation accrued less vacation taken. 


P 


4 


Y 


200.3 


SICK. LV. BAL. DATE 


Oate of the last balancing of sick leave accrued less sick leave 
taken. 


P 


4 




200.4 


SICK. LV. BALANCE 


The balance of sick leave accrued less sick leave taken Is 
maintained In this field. 


P 


4 


Y 


20} 




Optional segf^ent which contains annual accumilations of gross salary^ 
taxable incotne md taxes deducted for vaHous federal and state 
pro'jiKu^s t 








201.1 


YTO. GROSS. SALARY 


Gross dollar total of all salary for calendar year. 


P 


4 




201.2 


YTD. FED. HH. BASE 


Total dollars taxable for federal withholding for calendar year. 


P 


4 




201 


YTD.FED.HH.TAX 


Total dollars withheld from salary for federal Income tax for 
calendar year. 


P 


4 




201.4 


YTD. SOC. SEC. BASE 


Total dollars taxable for Social Security tax for calendar year. 


P 


4 




201.5 


YTD. SOC. SEC. TAX 


Total dollars withheld from salary for Social Security tax for 
calendar year. 


P 


4 




201.6 


YTO. STATE. BASE 


Total dollars taxable for California Income tax for calendar yt^r. 


P 


4 




201.7 


YTD. STATE. TAX 


Total dollars withheld from salary as California Income tax for 
calendar year. 


P 


4 




201.8 


YTD.SDI .BASE 


Total dollars base for State Disability Insurance for calendar year. 


P 


4 




201 .9 


YTD.SDI .AKT 


Total dollars withheld for State Disability Insurance for calendar 
year. 


P 


4 




201.10 


YTD. UCI. BASE 


Total dollar base for Unemployment Compensation Insurance for 
calendar year. 


P 


4 








An optional segment containing quarterly accwmtatione of gross 
salary, taxable incof^ and taxes deducted fot uai*towc federal 
and state prograns> 








202.1 


QTO. GROSS. SALARY 


Gross dollar total of all salary for current calendar quarter. 


P 


4 




202.2 


QTD. FED. WH. BASE 


Total dollars taxable for federal withholding for calendar quarter, 


P 


4 




202.3 


QTD.FEO.WH.TAX 


Total dollars withheld from salary for federal Income tax for 
calendar quarter. 


P 


4 




202.4 


QTD.SOC.SEC.BASE 


Total dollars taxable for Social Security tax (tr calendar quarter. 


P 


4 




202.5 


QTD. SOC. SEC. TAX 


Total dollars withheld from salary as Social Security tax for 
calendar quarter* 


P 


4 




202.6 


QTD. STATE. BASE 


Total dollars taxable for California income tax for calendar quarter. 


P 


4 




202,7 


QTD. STATE, TAX 


Total dollars withheld from salary as California Income tax for 
calendar quarter. 


P 


4 




202.8 


QTD. SOI, BASE 


Total dollar base for State Disability insurance for calendar quarter, 

,, /■ 


P 


4 





OASIS DATA ELtMENT DICTIONARY - EMPLOYEE FILE 



SEG SO, 
ELEH NO. 


ELEMENT 
NAHE 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


202.9 


QTO.SOI.ANT 


Total dollars withheld for State Disability Insurance for calendar 
quarter. 


P 


4 




202.10 


QT0.UC1.6ASE 


Total dollar base for Unemployment Compensation Insurance for 
calendar quarter. 


P 


4 




m 




Optioyiat segment holding annual aoQwmlaiione of hours worked and 
taken as time off for various reasons. 








203.1 


YTO.HRS.REG 


Cunnjlatlve total for calendar year of hours worked at regular hourly 
pay. 


P 


3 




203.2 


YTD.HRS.OVRTIME 


Cumulative total for calendar year of hours worked at "overtime" pay. 


P 


3 




203.3 


YTO.HRS.COMP 


Cumulative total for calendar years of hours due as compensatory 
time off. 


P 


3 




203.4 


YTO.HRS.VAC 


Cumulative total for calendar year of vacation hours taken. 


9 


3 




203. S 


yto.hrs.sick.lv 


Cumulative total for calendar year of sick leave hours taken. 


P 


3 




203.6 


YTD.HRS.PRCNT 


Cumulative regular hours worked as a percentage of regular hours 
available for work. 


P 


3 




204 




An optional seg^vent uhioh contains aaourrulations for the last 
payroll period of hours worked and taken as time off for various 
reasons . 








204.1 


LAST. HRS. REG 


Total hours worked at regular hourly pay during last payroll period. 




3 


Y 


204.2 


LAST.HRS.OVRTIME 


Total hours worked at "overtime" pay during last payroll period. 


P 


3 




204 .3 


LAST. HRS. COMP 


Total hours due as compensatory time off for hours worked during 
last payroll period. 




3 




204.4 


LAST. HRS. VAC 


Total vacation hours taken during last peyroU period. 




3 




204.5 


last.hrs.sick.lv 


Total sick leave hours tiken during last payroll period. 




3 




204.6 


I A^T HPS PRTNf 


l>CHUIul liUUI 9 nUT III 1 O a v ^QJFIUI 1 yl^t 1 wVJ a> a ^cibCllliO^C^ Ul 

regular hours available for work. 


j> 


3 




206 




Optional segnient containing aocount numbers aeeoaiated with charges 
for Stanford living areas and food services. 








205.1 


rm.acct.no 


Account number associated with charge for Stanford living area. 


C 


7 




205.2 


so. acct.no 


Account number associated with charge for Stanford food services. 


c 


7 




see 




An optional recurring segment holding employee retirement progran 
data includiKg annual and enp toymen t^to-date contributions. One 
Si^gment is generated fcr each type of retirement progran in which 
the employee enrolls. 








206.1 


RET. PL. contract 


Contract number of retirement program. 


c 


8 




206.2 


RET. part. DATE 


Date on which the employee entered the retirement plan. 


p 


4 




206.3 


RET. CREF. SPLIT 


Percentage of contributions allocated to TIAA. 




2 




206.4 


RET. YTD. BASE. AMT 


Total amount of employee contributions to the base plan (Prudential 
or TIAA) for the ye?r. 




4 




206.5 


RET.YTO^CREF.AHT 


Holds the total aw)unt of employee contributions to CREF for the year. 




4 




206.6 


REt.YTO^SU.AMT 


Total calendar year contributions to retirement plan made by Stanford. 




4 




206.? 


RET.PLAN.COOE 


Code designates specific type of retirement plan. 




2 





OASIS DATA ELEMENT OICTIOKARY - EMPLOYEE FILE 



ssa 

ELEH HO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


206.8 


RCI.su. TOTAL 


Total Stanford contributions made to the retirement plan. 


P 


5 




206.9 


f\tT. BASE, TOTAL 


TotAl contrl buttons to the s@ vp t1 rpm^n t nl An 


p 

r 






206.10 


R£T,CRCF,TOTAL 


Total contributions to CREF, 


P 


5 








Aotion Fom routing codes ccm dated on whi<ih tnformaticn wae ladt 
piytnted ok fovffid. 








207.1 


PR.CHK,RTE 


Campus address code where payroll check or direct bank deposit slip 
Is to be delivered. 


P 


2 


Y 


207.2 


PA.FORH.RTE 


CadlDUS address code wher@ thp ccMnoufpr nv^lntpd Ppr<nnnPl Arf tnrv 

form for employee fs to be delivered. 


p 


c 


V 


207.3 


LA$T,PAIO*OATE 


Payroll period date when ernployee was last paid. 


P 


3 




207.4 


PR, INF. CD. DATE 


Date on which last Payroll Information form was printed. 


P 


4 




207.5 


PR,INr.CO,lNDX 


Flag set during end-of-pay-period processing which 1r>d1cates 
reouirefnent for stib^eouert Pavroll iKkfomi^tion fnrm nr^ntinet 


c 


1 




207,6 


PA.fORM,P;^NT.OTE 


Date on which Jast Persoone} Action form was printed. 


p 


4 




207.7 


PA. FORM.PRNT. IND 


1 1 9c If uui iii^j ciivj^u 1 ^ajr ivu ^ivdi^>iii^ wmicii |iiupv>o^v9 

requirement for subsequent Personnel Action form printing. 


I* 


1 








Ah cpticKcxt reourHng e&gment vhich contains a i>orkiKg title arid 
department aod^ for use in preparing the Faoutty/Stnff Direotory, 








206.1 


WORK. OEPT, CODE 


Carnpus address code for department where employee is assigned 

;if!fli1 n f < trA 1 1 \/p1 v Thp t^Hp 1 < a1 <.n u taH InnanPifAff aa Aor\n v'^mAh f 
a wM iici3kiai>ivcij^, iiic cuuc I3 ai^u u>cu iiiyc'icraLiiiU Uc ua r i»iiicii L 

name in annual Faculty/Staff Oirectory. 


P 


2 


Y 


208.2 


WORK. TITLE 


Working title of efliployee used in Faculty/Staff Directory. 


c 


21 








A» optional eegynent holding a work looation and aeeooiated telephone 
nmberQ uJ^icjft are ueed in preparing the Faoulty/Siaff Directory ^ 








209.1 


WORK. LOCATION 


building nam? and room number where employee's principal work is 
Ideated. 


c 


20 




209.2 


PHONE. BUS . EXT 


Ph(%fiP pyfpnclAh niimhP'ir Af ^tAnfnyil 

r 1 rUI LC VCIlalUIIIIUilfUClCibOballlvrU, 


p 

r 


J 




209.3 


PHONE, OTHER. BUS 


Phone number of work location if not central Stanford number, 


P 


4 




210 




Optional recurring eegment containing visa inforrriation for employee 
of foreign natio^at'ttieB* 








21 Oil 


VISA.TYTE 


fndp Indlcafc'ino fhp tuDP Af vI^A Iceni^d ffi fhp Pmnliivpp - 




c 




210,2 


VISA, DATE 


Date th^t thp vl^a fs^ufrdi 

VQil>C lf<l|tlf ViiC *l9arfOI9 i99VivU. 


p 


..' *f ■ 




210.3 


VISA. CITIZEN 


Country of which eiDployee Is c1tl26n. 


V 


2 




211 




Optional segment which containe code indicating highest educational 
acHevementi and undergraduate and graduate etudiee infc:^tion* 








211*1 


EOUC. LEVEL 


Indicates highest level of educational achievement. 


c 


2 






fOUC.UG.YEAft 


year of Undergraduate degree. 


c 


2 




iiill 


feirc.uStOtfifiEE 


Ur^dergraduate degree code. 


c 


3 






foiucroo". MAJOR 


Major area of undergraduate study. 


p 


3 





OASIS OATA ELEMENT DICTIONARY - EHPLOYEE FILE 



$SG SO, 
illH HO. 


ELEKENT 
NAHE 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


If^DEXED 




EDUC.UG.INST 


Code of undergraduate educational Institution, 


P 


4 




211.6 


EDUC.GR^YEAR 


Year of graduate degree. 


C 


2 






EDUC.GR. DEGREE 


Graduate degree code. 


C 


3 




2\\ .8 


EOUC .GR. MAJOR 


Code designating tnajor area of graduate study. 


9 


3 




211,9 


EOUC.GR.INST 


Graduate degree instltotlon code. 


P 


4 








An optioruil eegff^nt which holds current military atatue inforvnticn* 








212.1 


MILIT.COOE 


Indicates status of employee In relation to U.S. military service. 


C 


2 




212.2 


HILIT.DISCH.DATE 


Date of military discharge. 


P 


3 




BIS 




An optional recurring eegment containing ernptoyment hietory yrior 
to applying for a Stanford position, I^ach eegment generated ie for 
a single preoioue Job. 








213.1 


PREV.EHPL TYPE 


Type of busfress engaged In previous to Stanford employment. 


c 


2 




213.2 


PREV.tMPL. SALARY 


Salary of previous position. 


p 


4 




213.3 


PR.EHPL.lv. CODE 


Code designating employee's reason given for leaving previous 
employment. 


c 


2 




213.4 


PREV.EMPL. JCC 


Stanford job classification code approximating work perfornved category 
In previous position. 


c 


4 




213*5 


PREV.EHPL.ZIP 


Zip code of previous employer's business address. 


c 


5 




213.6 


PREV.EMPL .ST .DT 


Date that employee started work for previous ^ployer» 


p 


4 








Optional recurring eegivent holding enployee leave dates, reason 
and 3tcitu8> One ocourrefice p^er leote* 








214.1 


IV. MO. TOTAL 


Total number of months that the employee has been on this leave. 


p 


2 




214.2 


LV. STATUS 


Oes1 inates the current leave status of the employee. 


c 




Y 


214.3 


LV. REASON. CODE 


Indicates type of leave and general reason for absence. 


c 


2 




214.4 


LV. START »OATE 


Date on which the most recent leave was started. 


p 






214.5 


LV. EXP. RET. DATE 


Date on v^hkh employee Is expected to return from leave. 


V 






214.6 


LV,ACT.«Er.OATE 


Date on which employee actually returned frdm most recent leave. 


p 










An optional recurriKg segment containing name^ hiHHdat'i ^nd 
relationship code for emplcye^'e dependent, One occur/^uce per 
dependent. 








215.1 


DEPENDENTvNA'^E 


Full name of a family dependent. , 




23 




215.2 


DEPENDENT.REL 


Indicates relationship with employee* e.g. > son, daughter* etc. 


c 


I 


Y 


215.3 


DEP. eiRTH. DATE 


OJrthdate of the dependent, ; r 


p 


4 




m 




Optional segrj^ent holding eumxr'!*cd monthly salaried: base, 
tupptement and grcs^. Also contains date by which e^nployee^e 
6atary should be reHe^ed. ' 












Total base monthly salary for paywil groups 2 and 3, Amount paid . 
-previous month for payroll group':'^, ' -j 


p 


4 \k 






^WpV. MO •SALARY 


Total supplementary salary, as for BASE. HO. SALARY. 




4 









lERJCv ; 



OASIS DATA ELEMENT DICTIONARY - 



EMPLOYEE fKE 



SB3 NO. 
ElEH NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


216.3 


TOTAL. MO. SALARY 


BASE.MO. SALARY and SUPPL .MO .SALARY . 


P 


4 




216.4 


NEXT. R£V, DATE 


Date by which the employee'^ salary or rate of pay should be 
reviewed. 


P 


■4 


Y 


21? 




An optional reourHng segment holding gro68 salary for each 
quarter of calendar year* One oo^urrenoe per year idth P)ax-Cmum 
of too oO'^urrenc€6, 








217.1 


PREV.QTO.YR 


Year of qi^arterly gross salaries recorded In this segment. 








217,2 


PREV.QTO. GROSS.! 


Gross saiary for first quarter of year coded 1n PREV.QTO.YR. 


I 






217.3 


PRlV.QTD.GR0SS,2 


Gross salary for second quarter of year coded In PREV.QTO.YR. 




; 




2]7.4 


PREV.()T0.GR0SS.3 


Gross salary for *.h1rd quarter of year coded In PREV.QTO.YR, 


p 






2]7«5 


PREV.OrO.GROS$.4 


Gross salary for fourth quarter of year coded In PREV.QTO.YR. 








B18 




Optional recurring segment hontaining salary and job olaeeifioation 
history data* One occurrence generated for each change in salary, 
job class ifioaiion or percentage of time worked* A maximm of six 
occurrences vill be allowed. 








2id.i 


SH. START. OATE 


Starting date of salary history data In this segment. 








218.2 


SH.STOP.DATE 


Date when some change of salary history data caused creation of 
this segment. 








218.3 


SH. ACT. TYPE, 1 


First Action Type code recorded which Impacted salary history data. 








218.4 


SH.ACT.TYPE.a 


Second Action Type code recorded >*hfch Impacted salary history data. 


c 


1 




216,5 


SK. DEPT. CODE 


Code of Stanford organization to which employee Is administratively 
responsible. 








218.6 


SH.JCC.l 


First job classification code assigned to employee prtor to 
creation of the salary history record. 








218.7 


SH.PRCNT.l 


Percentage of full time associated with first job classification. 


p 






218.8 


SH. JCC-2 


Second job classification code assigned to employee prior to 

LfCQblUIIUI bnc sola r Jr 11 f 3 LUr Jr icLli lU • 


c 


4 




218.9 


SH.PRCNT.2 


Percentage of full time associated with second Job classification 
code. 


p 






^18. 10 


SH. BASE. MO. SAL 


Base monthly salary at the time of salary history segment creation. 


p 






218.11 


SH.SUPPL.MO.SAL 


Salary history supplementary monthly salary. 








218.12 


SH.PR.6RP 


Payroll group at time of salary history. 












An optional eegy^nt which holds infouMtion on new position of 
terminating employee* 








219.1 


TERM. NEW. JCC 


Stanford Job classification code assigned to a new position of 
temlnatlrtg employee. 








219.2 


TERM. NEW. SALARY 


Salary attached to new position of terminating employee. 


p 






219.3 


TERM.NEW.JOB.ZIP 


Contains zip code of business location where terminating employee 
Is Intending to work. 








21 M , 


TERM, EMPL. TYPE 


Type of business at new position for terminating eiTjployee. 








iiq : 




Optional segmnt containing record of applicant refetral^ and results 
6f intervi&J3» 









OASIS DATA ELEMENT DICTIONARY - EMPLOYEE fILE 



ELEH NO. 


ticurijT 

NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


220.1 


APPL.REJ.AEASON 


Indicates the reason why an applicant was rejected for an open 
positlont as specified by the department representative. 


C 


2 


Y 


220.2 


APPL.REQ.NO 


Number of the personneV requisition submitted for the open position. 


P 


4 


Y 


220.3 


A?PL.!NTV,DATE 


Date on which the Job applicant was referred to a department for 
consideration. 


P 


4 




220.4 


APPl. RET. SOURCE 


Coded Indication of how applicant found out about Job opening. 


C 


3 








An optional eegment holding job ekille infomation for applioant& 
and employees deeiring tranafer or promotion. 








221.1 


TYP.SK.WPM 


The number of words typed per minute In a standard typing test. 


P 


2 




221.2 


FOR. LAN6.sk. CODE 


Proficiency In languages other than English Is Indicated by 
coding In this area. -> 




c 


1 




221.3 


SK.CODE.l 












221.4 


SK.EVAL.l 












221. S 


SK.C0DE.2 












221.6 
221.7 


SK.EVAL.2 
$K.C0DE.3 


Codes for types of skills are recorded In these four fields and 
evaluative ratings are Inserted In the corresponding areas. 


> 


c 


2,1 


Y 


221.8 


SK.EVAL.3 












221.9 


SK.C00E.4 












221.10 

m 


SK.EVAL.4 


_> 

Optional recurring ^.rgment which contains employee claims against 
Stanford insuran<y3 programs. One occurrence per alaifn. 








- 


222.1 


CLAIM. DATE 


Date on which tho e^Moyee makes claim related to Insurance program 
or workmen's comper-iat Ion. 


P 


4 




222.2 


CLAIH»AMT 


Amount of money employee claims Is recorded In this field. 


p 


5 




222.3 


CLAIM. TYPE 


Insurance program under which claim was made. 


c 


2 


Y 


222.4 


CLAIM. DISP 


Disposition of claim by Insurance vendor. 


c 


1 




222*5 


CLAIM»PAID.AMT 


Amount of money paid by Insurance vendor through date In 
CLAIM. PAID. DATE. 


p 


S 




222.6 


CLAIM. PAID. DATE 


Date of last payment to employee by insurance vendor. 


p 


4 




222.7 


CLAIM. NO 


This number Is assigned within CLAIM. TYPE by Insurance vendor or 
Stanford. 


p 


4 








Optional non-recurring segment containing initial enrollment date 
for selected insured benefit plans. 








223J 


1N1T,MM£0.DAT£ 


Initial date of enrollment fn major medical ,lan. 


p 


4 




223.2 


INIT. HEALTH. DATE 


Initial date of enrollment in health plan. 


p 


4 




223.3 


iniT. LIFE. DATE 


Initial date of enrollfnent in life insurance prografn. 


p 


4 








Optional recurring segment holding employee records of training 
program need and par t idipa tion, 














ill 


lilli 




iiiii 






11;. 
Ill 


iiill 
WS 





OASIS DATA ELEMENT DICTIONARY - EMPLOYEE FILE 



SEG ^JO. 
ELEH NO. 


ELEMENT 
NAME 


DESCRIPTION 


DATA 
TYPE 


LENGTH 
(BYTES) 


INDEXED 


224.4 


TR. END. DATE 


Coflipletior^ date of training program. 


P 


4 






TR. PROG. COST 


Cost of training prograrr, to Stanford. 


P 


4 




224.6 


TR.EMPL.EVAL 


Employee evaluation of training program. 


C 


2 





